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:
...
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. The process of transferring value from one shard to another will work like this:
Client software will need to provide the following data:
- The list of shards by which the transfer will take place (path from one account to the other, via an ancestor)
- Signatures for the transaction
- Deployments for Payments
Listening for Events
The validators in a shard have to be aware of certain events in the parent shard. These are:
...
- 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.
...