/
2018-07-18 Sharding Meeting notes

2018-07-18 Sharding Meeting notes

Jul 18, 2018

Date

Attendees

Goals

Discussion items

TimeItemWhoNotes
Existing contractsMichael Birch
  • There exists a link at the bottom of the page
  • Mint Contract review



  •  We need Rholang code and scala code
  • Rholang code handles requests for account holders in the child shard.  there has to be contracts that they can send the money to, along with a public key.
  • Validators need to be watching for messages on that contract.  They have to interact with the client api in some fashion (likely internally). They need to be notified that a message has arrived at the contract, and they need to wait for the block to finalize prior to acting on it.  Once finalized, they act as clients of the parent shard, making transfers from the depository.
  • Child level blockchain, parent level blockchain and a layer below that responds to finalization events.  
    • It makes sense to separate the communication layer between shards from Minting / burning etc...
  • When a validator set change takes place, they have to be issued a share in the K / N contract in the parent shard.  This cannot be done immediately.  This happens after there is agreement that the validator should be added.  Once finalized, then send messages to the parent to update the K/N contract, once finalized, then update the child shard.
  • Unbonding
  • Slashing
    • Cryptographic evidence to remove the validator.  Present it to the parent to remove the shares
      • Claim should be self contained in order to present to the parent.  Would have to be 2 signed messages, where neither is in the justification of the other.
  • Coalition
    • They can withdraw the money from the depository & no dealing with the coalition.
  • The cross shard service
    • Client software built into the validator so that it can act as a client of another shard.
      • Built in Scala
      • Client module that will monitor what is happening on the child shard & the parent shard using RHOL-440  It will operate as a proxy, shuttling messages between those 2.
      • Child Shard validators watching events in parent
        • Bonding/Unbonding event 
          • Pushes actions on to the parent to change the K / N contract
          • Child watches for this action to finalize
        • Minting Rev 
          • Calls the depository contract to validate the amount of Rev in the depository
          • Only mints the delta between the supply in the shard and amount in the depository
      • Gathering signatures
        • Each validator sends their own message

Concerns
  • Validator rotation - Immediately affects the branch in question.
    • Bonding
      • Message with intent to bond → sends message to Parent with message → finalization → approve bonding request
  • Validators as clients
  • Wallet → anyone can deposit.  Alice signs the message to transfer money with her private key.  The shard will generate a wallet, put money in it - which she can retrieve by using her private key.  
    • Alice does not need to have a wallet in the parent shard.  It always creates a new public name to create the wallet at.  If she already has one, she can transfer into her existing wallet.
    • Creates a purse, new wallet and registers the wallet as a public name & notifies Alice of what the name is.

Action items

  •