2019-05-06 Meeting notes: Mercury criteria review

Resources

• https://github.com/rchain/rchain/blob/dev/docs/features.md

Nodes section

• Complete

• TODO validate location of the documentation.

• Nice to have

  • Improved documentation
    
    

P2P network section

• Complete

Network launch section

• Complete

• Concern - We don’t have full coverage for ways genesis ceremony could fail. Need more information provided to users why it failed.

• TICKET - Update not a successful tests to lower duration it can run.

Contract deployment section

• For the two tests listed by name, are contract deployment tests updated to support cost cost accounting?

• Need next steps for:

  • As a user I want to know how much REV my deployment will cost

    • Consider and edit: As a user I want to estimate how much REV my deployment will cost.

    • QUESTION is this what Will’s working on?

      • Comparison of a dry run and and a subsequent run

    • TEST evaluate a contract (with Artur’s ticket in so it includes the state of the blockchain) n and have returned the cost to deploy the code

      • TICKET select 2-3 contracts to use in this test that are deterministic

        • Suggestion to use contracts in cost accounting

  • As a dApp developer, I want a contract to be able to call another contract so that I can take advantage of another contract's functionality

    • TEST https://rchain.atlassian.net/browse/RCHAIN-3341

      • Register the contract

      • There exists a contract in the registry

      • Share name

      • Look up

      • Invoke Call the registered contract with a different contract

  • As a dApp developer, I want contract definition inside another contract (ex WIDE, persisting contracts).

    • TODO remove this. This is covered by the Rholang language.

  • As a dApp developer, I want support for including binary files as part of deployments.

    • RSong is doing this with tooling in the platform. It requires conversion of the binary file using hex encoding.

    • DECISION remove this. This is not a mainnet feature. There is a way to do this (RSong). We do need to deliver this later.

  • As a dApp developer, I want STDOUT to go back to gRPC response and not the log.

    • DISCUSSION this is not a reasonable requirement. It would fill up the logs of a validator. ListenAtName or event approach will fulfill this need and in a better way.

    • TODO remove this. As described above.

  • As a dApp developer, when I make one or more deployments, I want a receipt of the transaction.

    • Is my deployment in a block? or Is my deployment still in the queue (ex ETH mem pool)

    • Example of how it’s done on ETH using MyEtherWallet

    • Concern that the exact words of this are not accurate. Agreement there is a sentiment of wanting confirmation about what happens to your deployment.

    • IDEA

      • use the deployer’s signature to track the d

      • use the validators' signature to track the proposal

      • use the block has to track the deployment to the block

    • TODO reword “As a dApp developer I want to be able to track my deployments.”

REV section

Wallets section

• Do we have the updates reflected from Ed?

• Which of the line items are now covered by tests?

Validation section

• Complete

• Discussion about “As a RChain validator, I want my validator identity to be different from the identity of my node and from the identity of my wallet.”

  • Agreement the sentiment is a concern of sharing private key in a scenario where there is a validator working with a devops person and who doesn’t want to share a private key.

  • TODO remove. Because we capture this information in documentation for how the platform works.

Bonding/unbonding section & validator slashing and ejection section

• Need to specify tests

Consensus section

• Complete

• Nice to have

  • Wordsmithing for clarity

Cost accounting

Name registry

Performance

• How do we share output of the perf test harness

Documentation

• There is a lot of work to do