Shard Enclaves, Private Data, Private Code Concepts

Merging Private and Public blockchains on a Single Layer

By: David Beberman, CTO

Introduction

The general case for SagaChain is that all blockchain data is publicly visible (although may be encrypted), all code is publicly visible and executable, all nodes can process any transaction on any shard, all nodes are permissionless, and all node software is open source. This model works well for trustless interactions among anonymous, pseudo-anonymous, and masked certified accounts. It is of less value to trusted interactions with non-anonymous account, with private data, private code, and private node software.

An objective of SagaChain is to support a mix of fully trustless and partially trusted accounts, nodes, shards, and software. To accomplish this SagaChain introduces the concept of shard enclave. Enclave meaning private or segregated within the SagaChain as a whole.

Enclave Shard, Node, Account and Code

An enclave is defined as a combination of enclave shards, enclave nodes, enclave accounts and enclave code.

· The enclave nodes are authorized to execute transactions on enclave accounts — such a node may be exclusive, or a mix of enclave accounts and general accounts.

· Enclave code is supported by “enclave language runtimes”. That is, specialized language runtimes that only execute enclave code — e.g. private classes.

o A hard limit for security purposes is that private classes can inherit from open classes, but not vice versa.

· Blocks created by an enclave shard may contain private enclave transactions — such transactions consist of the SagaPython transactions script, the hash of the output state of the enclave accounts, and the hash of the output log.

o The enclave blockchain does not include the actual output state. All such state is assumed to be stored off-chain and outside the scope of the SagaChain for verification purposes. A new node joining SagaChain can only verify that blocks from an enclave shard are wellformed with respect to enclave account transactions, not that the state of such accounts is valid.

· Conversely, an enclave node can obviously validate the enclave transactions.

· An enclave shard consists of enclave nodes authorized to view the enclave data, execute enclave code, and generate shard blocks containing opaque transactions.

Even though non-enclave nodes cannot validate enclave accounts, they do need to account object information — this is needed to determine that the account is an enclave account. However, any details of objects owned by the account are opaque to the rest of SagaChain.

An enclave account and a non-enclave account can message each other, provided appropriate permissions exists. However, the transaction can only be executed on the enclave shard. The resulting transaction output must include the full non-enclave account state update.

SagaCoin Management Rules with Enclave Shards

· To avoid “counterfeit” SagaCoin creation, an enclave account can not increment or decrement SagaCoin balance of a non-enclave account.

· The amount of coin that an enclave node can mint is prorated based on the number of non-enclave account transactions. That is, enclave-only transactions do not count toward coinbase minting.

· Gas unit charges apply to all transactions both enclave and non-enclave. Because enclave transactions are opaque to the rest of SagaChain, the gas units charged are the average of all non-enclave transactions in the block, with a lower limit of a rolling global average per-transaction gas-unit charge — (which is tbd but can be calculated). This forces the enclave clients to follow the general gas costs, which enforces the Foundation transaction tax on enclave transactions without requiring knowledge of the actual transactions.

· An enclave account, by definition has no SagaCoins assigned to it. An enclave account could send a message to a non-enclave account that causes SagaCoin to be transferred to another non-enclave account — this would be a means for accounts to pay each other without exposing the balances.

Enclave Shard Groups

A group of shards can be part of the same enclave. This enables scaling of enclaves provided sufficient enclave nodes are available. The L2L protocol is used for account ownership assignment, however, the enclave accounts are only assignable to shards of the given enclave. A shard leader requesting account ownership of an account it can’t execute should be ignored. Similarly, an account assigned to a shard that can’t execute it, should be ignored. The L2L protocol consensus should not succeed with invalid assignments

Designating Nodes and Accounts for Enclave Shards

An account may identify itself as only executable on shards meeting a specific set of parameters. This may be enforced by creating a subclass of ClassAccount specific for the designated enclave. A user creating such an account enables the account to join the enclave. A node attempting to execute methods on an object instance owned by a given account must be on a shard that matches the security parameters for the account. The transaction may include such account information, and the CMI must verify for each message dispatch that the shard is authorized for the account owner. That is, for each message dispatch, the CMI verifies that the target object and its account owner authorize receiving the message.

A node must be authorized to execute transactions on a given shard. Nodes are represented by node accounts. Authorization of the node account enables the node to execute on the shard. Enclave shards must be explicitly created as opposed to dynamically created with SagaChain scaling. Such nodes may be exclusive to such shards or may be available for other shards. Nodes joining an enclave are considered permissioned. The means for exchanging the authorization material is specific to the enclave users and outside of scope for SagaChain. However, SagaPython classes may be developed to facilitate shard, node and account authorizations.

Enclave transactions

Accounts on an enclave shard usually imply that the nodes are using off-chain data. On chain data may be limited to hashes of the output, hashes of the state, and the transaction messages. No state rollback outside of the enclave nodes is possible, only replacement of the current hash of the state with the rolled back state, as the true state data is not available.

Transactions between enclave accounts and non-enclave accounts are only executable on the enclave, as the enclave account execution is dependent on the enclave nodes. Messages can be resolved between open accounts and enclave accounts by the CMI normally. The method tables of enclave classes must be globally visible, while the method code may be encrypted or kept off-chain completely. The resulting blocks with transactions between enclave and non-enclave accounts must include the non-enclave account state updates as part of the transaction results just as any open transaction.

Enclave Minting Prohibition

Transactions that increase/decrease the SagaCoin count are prohibited between enclave and open accounts. Enclave nodes cannot mint coins for enclave transactions. A block received from an enclave containing an invalid coin mint shall be ignored by all other shards, and no future blocks shall be honored by the enclave. The enclave shall be considered terminated. No account state changes honored. The enclave shard leader shall not be allocated additional account ownership, etc.

Enclave Partial and Full Breakaway

An enclave shard or group of shards may consider breaking away from the SagaChain at some point. This would entail no longer distributing finalized blocks, no longer participating in the L2L consensus protocol, no longer acquiring new nodes from the SagaChain pool, no transactions allowed between SagaChain accounts and enclave accounts. There is nothing theoretically wrong with this behavior. The enclave shard blocks will no longer enjoy the additional proof-of-work hash power of the rest of the SagaChain, thus decreasing the long-term security of the shards. Scenarios where such behavior makes sense are unknown at this time.

Any shard that “breaks away” will appear to have terminated by SagaChain. Further, the accounts shall not have their state updated. Thus, a break away is a one-way operation, with no return.

Private Class Code

Private class code implies that the language runtime executes code that is not stored on SagaChain. This requires makes a language runtime that supports such private code. The language runtime may be dynamically added to SagaChain using the same metaclass model for any other language runtime. Other means for adding such a runtime are outside of scope of SagaChain.

Private code consists of methods of private classes. A private class is an object that is owned by an enclave account. The CMI shall not execute a transaction on an enclave account on a non-enclave node. Therefore, dynamically adding private language runtimes to non-enclave nodes is prevented.

A requirement for an enclave node is that it is able to execute all private code for the enclave. If this is not enforced, then the consensus validation protocol for the enclave shard will fail. It is up to the enclave operators for enforcement and outside of scope for SagaChain.

Private Class Inheritance

A private class may inherit from a public class with no limitations. The public class code will be executed on the enclave shard. There is no limitation on public class code executing on enclave shards. This directly implies that an enclave node must be able to execute all public language runtimes and public code in addition to any private language runtimes and private code.

Conversely a public class may inherit from a private class. Just as with the private inheritance above, the private class forces execution to be restricted to enclave shards. Further, a non-enclave account is restricted from executing private class code of any kind. Therefore, any transaction involving inheritance of a private class implies that the transaction’s account state updates are opaque. There is little value in a public class inheriting from a private class.

Cross-Enclave Messaging

Messaging from one group of enclave shards to a separate distinct group of enclave shards via enclave accounts is not supported. Messaging via public accounts is accommodated directly by the SagaChain protocols. The contents of the messages may be encrypted by the enclaves exchanging data as desired.