Definitions
...
- What is lost - the ability to use OCaps security between the shards.
The following Code block can be exchanged across shards:
| Code Block |
|---|
new x in {y!(*x)} |
...
| Code Block |
|---|
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 Sharding Client
The validators in a child shard are clients of the parent shard. This has a few implications:
...
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
- The validators go through the process of Initializing the blockchain.
- A validator creates a depository contract deployment in the parent shard that includes the validator list (ip addresses, node id and public keys), K and shard name. K should be a proportion of N (% needed to pass a vote)
- All the Validators then send (purse, signature over the above tuple (genesis hash, validator list, k) to the newly created depository.
- Once the depository is created, then the genesis block is created, and the validators are bonded. The depository generates the genesis block for the child shard. – Need the information that is contained within an approved Genesis block.The Mint contract is updated to include the K / N parameters for the shard.
- When a shard is mounted, Rev minted in Genesis will be minted as part of the genesis block.All of this Rev will be the bond amounts for the validatorsbacked by Rev in the depository.
Transferring value across Shards
...
- Need more specificity from Michael Stay (Unlicensed) on this.
Questions:
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.
...