Shard - a set of validators working together to validate transactions and create blocks. Validators in one shard can be clients of another shard, but they cannot exchange unforgeable names.
The following Code block can be exchanged across shards:
new x in {y!(*x)} |
not
y!(*@{182acdb344-7fd533-bbd5433cfe}) |
Shards support unforgeable names within the validator set. A block proposal containing an unforgeable name from a validator within the validator set is fine. Both of the above code blocks are supported within a shard.
The validators in a child shard are clients of the parent shard. This has a few implications:
A group of Rev holding validators come together and decide they want to spawn a new child shard.
If the shard wants to engage in cross shard transfers, and is not a child of the root shard, then it is advisable that validators in the shard validate transactions in the parent. To do this, they will need to stake that shard separately.
Steps
By sharding the blockchain, in essence we create 'altcoins' in each shard. Rev will exist in the rchain shard (the root shard). All other shards will have token that will be 'backed' by Rev, much in the same way that currency can be backed by gold. Tokens in shards will be exchanged for Rev in the rchain shard with a 1:1 exchange rate.
The process of transferring token between 2 shards requires invoking a contract in the nearest common ancestor of both shards. The platform will only support the atomic transfer from a child to a parent and a parent to a child.
Client software will need to provide the following data:
The validators in a shard have to be aware of certain events in the parent shard. These are:
Events in the child shard they have to be aware of for the purposes of updating the depository parameters:
Note: the session id is also used in the k-of-n contract to relate the validator's message to an active request.
//session id creation contract newId(return) = { new id in { return!(*id.toByteArray) } } |
Outbound Token Transfers
Users are familiar with urls and uri formats. Therefore it's reasonable to treat the hierarchy of shards as one would treat a directory structure, and reference them in the same way.
As part of testnet launch, the Core dev team will create the number of shards that are needed to demonstrate network performance of 20,000 tps (40,000 would be even better). The actual number of shards will depend on the performance of a single shard.
The root shard will contain the genesis block for the network. It shall be called 'rchain'
If shards A and B are both children of the root shard, they would be referenced as rchain/A and rchain/B
The blockchain of the parent shard will store information about it's child shards. This information is:
The above information should be sufficient for a Read only node or client to build a tree of the shard structure similar to a blockchain explorer.
Other information that is available for a shard on the blockchain:
Note: between 3 and 7 the new validator is bonded and can effect consensus, but cannot participate in communication with the parent until 7.
Question: If the validator has funds locked up in the K/N contract, those funds should be held until the unbonding wait period expires.
The blessed Mint contract will exist in each shard. While the master Rev mint contract (our version of 'gold') exists only in the rchain shard at the root of the tree, all other shards have pegged their token supply to the token supply in the root shard. The mint contracts in all the shards have to mint tokens at the same time, such that the exchange rate for Rev between the shards remain 1:1 all the way up to the rchain shard (root shard). The blessed Mint contract will be a K/N contract that is created by the K/N Sharding contract
Transfer the token from fort knox out to the new mount point. The K/N contract is invoked, and the required number of validators need to agree on Exodus.
Because Rchain is more of a concurrent/sharded blockDAG than the Ethereum-style sequential blockchain, does that mean each namespace is effectively a baby-chain with its own set of validators akin to a zone in Cosmos... just without the main chain? For instance:
I am operating in namespace A with 1000 REV and request to use a dApp operating in namespace B that requires 100 REV.
The validators in namespace B ask the validators in namespace A to lock 100 REV for the computation, and to burn those 100 REV if successful.
Namespace A passes a message to namespace B with my new account balance of 900 REV, contingent upon successful execution of the dApp.
The dApp executes, and namespace B passes a message back to namespace A notifying the validators of the success.
My 100 REV are effectively burned, and both namespace A and B have confirmation that my account now has 900 REV.
Medha Parlikar (Unlicensed): That is correct. The Sharding proposal for Mercury is akin to side chains.
If the above example is correct, where is the single trusted source of truth for what my account balance is, if not on a "main chain"? Or is the possibility of double-spending effectively solved by Casper correct-by-construction?
Medha Parlikar (Unlicensed): If a DApp is running in a child shard, we recommend validation of parent and grandparent (if applicable) shards. Tokens in child shards will have to be backed with Rev in the root shard. It is in this shard where the transfer happens. In all other shards, minting and burning takes place.
If a competing blockchain wanted the ability to do concurrent tx processing, say on a GPU, why wouldn’t they just force all txs to include a “header” that lists all accounts affected by the transaction? The VM would then be able to parallelize txs because it knows they won’t interfere with one another, right?
Michael Stay (Unlicensed): - Can you weigh in here?
How do developers choose which namespace their dApp operates in? Since different namespaces will have different policies for security, contract size, and privacy, will dApps interoperate across namespaces or will developers have to choose which namespace parameters their dApp will require in order to run, limiting usability?
Medha Parlikar (Unlicensed): We envision developers being able to browse the shards through some de-centralized mechanism, where they can learn about the properties of the shard prior to deploying their application. Michael Stay (Unlicensed) keep me honest here, but if a dApp developer is dis-satisfied with the security or performance of the shard they have selected, they can move to another shard. App developers will be given their data real time from validators, so moving their application should be a non issue. It is a matter of pointing their transaction endpoint to another set of validators.
How would development of Cryptokitties (as an example) work on Rchain? Could two of the same kitty be created in different namespaces and clash? Would love to walk through actually deploying a dApp and how it would interact with the Rho-VM.
Medha Parlikar (Unlicensed): The Cryptokitties app would run in a single shard. All the application data would exist in that shard. Yes, if Cryptokitties chose to move to another shard, they would have to take some steps to ensure that no 2 kitties are alike.
How will Rchain defend against Sybil attacks for named channels, or against squatters for namespaces/channels? Will there like a Rho Naming System similar to ENS for Ethereum? I assume creation of a namespace is effectively permissionless without an "RNS"
Medha Parlikar (Unlicensed): Correct -this is planned as part of the Public Name registry. We intend on having a DNS Oracle, where ownership of a public name would be checked against IANA's list. The registrant would likely need to provide proof of ownership of the domain in some fashion.