eddyashton
commented
4 years ago Thanks for the detailed descriptions! There's definitely some details here we need to explore further.
Questions
I have a few questions that would help us better understand your coconet proposal:
- What state is held in the Lithium coconet?
- What does a write in the Lithium coconet do?
I think your proposal is similar to sidechains in the Ethereum ecosystem, where the sub-networks are fundamentally independent but, in normal operation, work with authoritative data from the central network and store some results (or a derivation of them) on the central network. Does this sound correct?
As an initial response I'd like to explore how much of this functionality may already be possible in CCF.
Fair billing
The short answer here is that CCF should be unopinionated on how consortium members allocate and pay for the service's resources. They may decide that costs are apportioned per-node (each member must run N nodes), per-member (each member pays a flat fee, a separate operator provides minimum performance guarantees), per-transaction (the app counts tracks a transaction quota), or perhaps other models we haven't thought of. We believe we can support all of these under the current design.
Member-to-user association
We can track these within app logic rather than purely by restricting node access. As I see it, your proposed requirements are:
- each user is part of a specific member's organisation
- members don't care about the precise identity of other organisation's users
- members want to be able to restrict/audit each counterparty's transaction volume for billing fairness
This is possible in the current code. The governance script would allow members to add new users without a vote, but require that these proposals also associated the new user with the proposing member (by listing the member's ID in the user's user_data). Then the app logic can make a choice based on the member ID that is 'responsible' for the incoming transaction - perhaps decrementing a governance-controlled per-member transaction quota, perhaps only revealing this organisation's private data, perhaps counting the per-org transactions to be examined later.
Sub-networks
I think the safe way to implement org-specific networks or side chains is to reason about them as ordinary users. It may be that the hosted app is a central, authoritative database, and each organisation mirrors that on a local system for their own workloads (and perhaps that local mirror-system is also a CCF service). But if we treat these mirrors as users (ie - some authorised proxy is fetching state from the central service, and submitting write requests produced by the local service) then we understand the consensus model (the user should generally only work with globally committed values, anything else may be rolled back). If we start talking about sub-networks, or gateway nodes that are part of 2 networks (?), then we need to think carefully about what state they're sharing and how consensus is reached over it. In particular, this risks the stumbling block of many other blockchain systems where private data is stored only in specific nodes or sub-networks, making cross-org consensus and transactions more awkward.
User identity management
The member responsibility for matching a user cert with a real-world identity will vary significantly between CCF instances. In the organisation consortium case you discuss it makes sense to build a member-to-user mapping as outlined above, to track a member -> set-of-users relationship, with each member solely responsible for verifying their proposed users.
But CCF can also be used for public scenarios, where the members have a shared interest in providing a service but the users may be unaffiliated. Since we're currently using TLS certs for auth, we fall back to existing solutions for pairing certs with identities. Perhaps the members fetch the user's cert from some external trusted PKI, perhaps they only accept certs provided in-person. We'd like to make this easier, by exposing efficient cert-inspections helpers to the scripting environments, and perhaps moving away from cert-identities (instead relying on something like Azure Active Directory to authenticate users). These are still early discussions.
Sorry this response is a little dense - I had several things I wanted to mention and haven't organised them very well!
douglasism
achamayou
Preface As a way to learn about CCF and attempt to reach an understanding of its design and implementation, I've been imagining how it might be deployed at scale. As soon as I began to consider this, I started wondering about how all of these nodes would be hooked up and how the consortium would pay for all of the network traffic and the compute cycles and the storage. (Costs are on my mind because I let my tinkering in Azure get out of hand last fall --- it ain't free.) This exercise has several benefits for me, and I hope that you don't stop reading my proposal when I admit them.
First, I don't have much experience running large scale operations. This exercise is a driver to help me at least become conversant about large-scale operations. Second, the interconnected weave of security guarantees in CCF is quite complex and as I'm still learning about it, I can't yet say that I'm aware of and understand it all. There are gaps. Further, this is a 0.1 proposal, without any previous review. I don't claim that it is sound. My purpose is to generate discussion around these ideas.
If you are still reading this, great! Let me get right to it then. Here is a diagram that is intended to capture the current design. It's based on a diagram in the CCF documentation. I will use it as a basis as I develop these ideas. I'll call this the open design.
The "Open" Design
As I've said, this is as it is today. I won't dwell on it.
Next up is a configuration that @eddyashton mentioned in the CCF chat room. (I hope I represent his design correctly.) In this network configuration, only users that are associated with a member have access to that member's network interfaces. This is accomplished through the member’s network infrastructure and would not require any design or implementation change for CCF.
The "Network Segment" Design
What does it achieve? In my miserly design exercise, I don't like the prospect of my friendly consortium partner having their 1.2 million customers channel transactions through my resources. Let that traffic go through their consortium network nodes! Of course, at some point, my systems will carry some of the load of their customer's transactions, given that we have a common ledger, but at least the initial phase should be handled by their systems. (I also have an idea about how to get paid for that too. I’ll cover it later.)
So far, nothing has been proposed that would require a design or implementation change. But the next variation will. I call this the "CCF Segment" design. It accomplishes what the "Network Segment" design does, but CCF does it natively. In addition to what "Network Segment" did via network configuration, this design proposal lays a part of the foundation for the central idea of this proposal: the CoCoNet, which we'll come to soon.
The "CCF Segment" Design
The core shift of the "CCF Segment" design is that the users become fully associated and managed by the member. The users table is private to the member. There is no proposal nor is there voting on admission by other consortium members. (I’m still perplexed with the concept that members would have the practical means of vetting other member’s proposed “users”. With a decentralized, heterogeneous consortium, how would that process work? What is the common trusted authority for identity and authorization across the consortium? Beyond validating the presented cert, how would voting members know if AAAAB3NzaC1yc2EAAAADAQABAAABAQD should be allowed to call the application interface?) A new "user" entity becomes known throughout the consortium through “account” creation in the common ledger. The user's status is maintained in the ledger globally, and privately within the member's identity and authorization scheme, whatever that may be. The member is vouching for the identity of the user. If there are bad transactions from that pubkey, the responsibility is partly the member’s. They designed and run their identity and authorization systems. There is more to be said here, but I will move on.
And now the CocoNet proposal! Thanks for staying with me so far. Please take a look at this diagram:
Edit
This idea is flawed. It has been retracted. Please see my comments below.The CocoNet phase 1: Consortium spin-up
This is quite like today's design. But notice there are no users. This CCF network was loaded and spun up without any users (in the current design's sense). And perhaps your interest is piqued by the nodes labeled "gateway". Let's view the next phase of the CocoNet. Users are about to arrive!
The CocoNet phase 2: Member Lithium arrives
Edit
This idea is flawed. It has been retracted. Please see my comments below.This is a core element of the proposal: Lithium operates a fully functional CCF sub-network with the major, significant caveat that it has to connect to its counterpart gateway in the core consortium network for its sub-CCF network to be joined --- for it to receive the coconet keys. At this point, with just one member's users, the consortium is fully operational. This proposal leaves most of the current design and implementation intact. The operation of the subnets are very much like the operation of the core consortium network. It's fractalish. Let's bring in Krypton's user base. There are many!
The CocoNet phase 3: Member Krypton arrives with its large user base
Edit
This idea is flawed. It has been retracted. Please see my comments below.Replication occurs across the entire consortium and member subnets. The same algorithms are applied across all nodes. The subnets collect transaction blocks and forward them to the gateway, in the core consortium. In this role, the subnet 0 node -- the subnet's primary node --- also behaves like a common node, relative to the core consortium, where the core ledger update occurs. The results are fed back through the gateways to the subnets. The whole is made of fractal-like subnets, but operates as if it were one CCF network.