Possible? Private Permissioned Distributed Ledger


#1

I’m just getting my toes wet with Sovrin in a VM. The getting started guide has been very helpful. It’s a little out of date but nothing too bad. I am getting stuck tryingi to accept the Faber College invitation on the test network (status tells me ‘Attempting connection to test Sovrin network’).

Before I invest too much time, I’d like to make sure I’m not heading toward a dead end. I’d like to build a proof of concept for a private ledger (LAN, for now) of peer devices that can engage in trusted communication using public keys of authorized users and devices stored in the ledger. For now, I am just concerned with public keys in the ledger, but I’d eventually like to store different metadata.

I imagine it going a little like this - start with a root of trust, like a provided key for example. A device is the genesis of the ledger, accepts the key as the root of trust, and waits for nodes to talk to. A node joins the network by accepting the root of trust and joining, and so on and so on. Transactions on the ledger (such as adding a trusted user or node) are accepted if they are signed by the root of trust or another trusted key.

The intent is to create a network of trusted nodes that only perform privileged (high risk) communications (firmware update, console login, etc) with other trusted nodes by referring to the ledger.

Can Sovrin accomplish this as is? If requiring a fork, would it be a lot of hacking to make it behave this way? Is there a better way to achieve my intent?

Thanks for your help!

Bradford


#2

Bradford, this is very interesting question. As you probably know from the white papers, the goal of Sovrin is to provide a public permissioned ledger, so that’s been the design center for the open source code base. But it has come up before that the code could be used for private permissioned ledgers that needed the same basic set of transaction types.

But I’m not the guy to explore it more deeply at a technical level—we’d need one of the developers to weigh in. I know several of them are tied up at an industry meeting this week, so it may be a few days before you get an answer.


#3

Thanks for your input. It seems like my use case is more of a ‘sidechain’ to Sovrin - it could interact with the Sovrin ledger (using a Sovrin identity as a root of trust would be awesome) but as a sidechain it could be configured for different purposes - storing different data on the ledger that would be inappropriate to store on the Sovrin ledger.


#4

Bradford: in rereading your messages, it seems like you have two use cases:

  1. Establishing a registry of trusted public keys.
  2. Storing various types of data associated with those keys.

Sovrin is a good fit for your first requirement, and would not require a sidechain. Sovrin may not be a good fit for your second requirement since it is not set up to store arbitrary data. Rather it is optimized to store the data typically require to bootstrap trust relationships. To wit:

  1. Identifiers—specifically DIDs
  2. Public keys—stored in DDOs (DID descriptor objects)
  3. Service endpoint pointers—also stored in DDOs, which tell you how to interact with an agent for the identity owner
  4. Public claims—publicly available identity attributes or relationships (useful for public identities, whether individuals or enterprises)
  5. Proofs—various types of cryptographic artifacts that do not contain PII (personally identifiable information), but which can be used to prove the existence and revocation status of a private claim or consent receipt.

If the data you need stored is not one of these types—all of which are relatively small—then you’d likely need some type of side chain or distributed storage service like IPFS for the data storage component.


#5

This is a very interesting thread, and one topic I’ve been pondering about as well.

I’d also like to know how much “sense” does it make from the Sovrin project perspective the implementation of private “domains” or Sovrin “sidechains” that are somehow pegged to DIDs and claims on the Sovrin ledger.

On another subject, what @bradford wants to achieve could be done by setting up a flow for private data exchange between Sovrin agents with “no disclosure” cryptographic proofs anchored on the public ledger. Isn’t that right?

…I’m really interested in discussing these matters from a technical and “philosophical” point of view: how “in alignment” with the present Sovrin intent is this type of architecture? How secure do developers consider such a scheme, and which other alternatives do we have for achieving our goals?

There’s no doubt that private data is going to be a fundamental part in any web of trust or digital identity network. The questions are then:

  1. Do we need private ledgers?
  2. Do we gain anything from the use of private ledgers?
  3. Is the Sovrin architecture permisive for the implementation of private Sovrin “sub-ledgers” (or sidechains)?
  4. Can a good private data exchange protocol between Sovrin agents render the idea of private ledgers unnecessary or even “obsolete”?

I’m looking forward to delve deeper into this subject.


#6

@cbruguera, I agree, this is a fascinating subject. A few thoughts below.

Yes, no question about it. In fact the only question in my mind is: “How often can the use case be achieved entirely by private data flow between Sovrin agents and how often will it require a separate private ledger?”

I don’t know the answer, but I suspect it’s at least 90/10, i.e., a maximum of 10% of the use cases will require a separate private ledger.

Since I know of at least one set of use cases that will use a private ledger (the CULedger being developed by the U.S. credit union industry), my answer is “Yes”. There are definitely cases where a private ledger can journal transactions for shared access more efficiently than off-ledger agents. But I believe that will be the exception and not the rule.

Absolutely. Any agent can “anchor” transactions from private ledgers to the Sovrin ledger for any use case than requires it.

See my answers above. But only time will tell. Let’s build it and find out!