2018-11-07 Main Net Feature Requirements

Date

Nov 7, 2018

Attendees

• @Ned Robinson@Lucius Meredith @Deanna Duke @Kelly Foster @Ovidiu Deac @Pawel Szulc (Unlicensed) @Adam Szkoda @ArturGajowy (Unlicensed) @Former user (Deleted) @Łukasz Gołębiewski (Unlicensed)

Goals

• Discuss high level feature set (MVP) needed for Mercury launch (see below) - are there other high level features that need to be included?

• Prioritize feature list (not so much implementation) and begin breakdown into product backlog items

• Map the items in Greg’s timeline to MVP feature set for Mercury - if any on the timeline don’t map to the MVP, place in “parking lot” for future releases https://docs.google.com/spreadsheets/d/1_yOk4TcBV2k3Lk5Qp1DtGJwbURpuuPIYHP_dSk-PlB8/edit#gid=450491259

MVP Feature Set

Nodes

• Software installation (As a Node Operator, I want to install software from binary artifacts or a Docker image)

• Software operation (As a Node Operator, I want to run software on Linux, MacOS, and in Docker)

• Standalone mode (REPL and EVAL support) (As a dApp Developer, I want to interface with the Rholang interpreter and evaluate smart contracts independently from the blockchain)

• Configuration (As a Node Operator, I want to have a default configuration and the ability to customize the configuration on the command line)

• Monitoring (As a Node Operator, I want to monitor the performance, resource consumption, and status of my node)

• Private key privacy (As a Node Operator, I do not want to expose my private wallet key on the command line)

Peer to Peer Network

• Nodes connect to peers

  • As a Node operator, I want to be able to bootstrap to the network by connecting to any known node.

  • As a Node operator, once connected via a bootstrap node, I want to discover and connect to peers.

  • As a Node operator, I want to know how many peers I am connected to.

  • As a Node operator, I want to remember my peers so I can reconnect after a restart.

• Nodes communicate via TLS (Transport Layer Security) for node discovery

• Nodes communicate via Kademlia (secure or not?) for protocol handshake

• Nodes broadcast messages

• Nodes process blocks (needs clarification)

Proof of stake consensus

• The platform uses a proof of stake consensus algorithm

Wallets

• Create a wallet (As a user, I want to be able to create a wallet so that I can store tokens in it)

• Add tokens to a wallet (As a user, I want to be able to add tokens to my wallet so that I have available tokens to pay for goods/services)

• Remove tokens from a wallet (As a user, I want to be able to remove tokens from my wallet so that I can pay for goods/services)

• Expose purses inside a wallet

• Destroy a wallet (As a user, I want to be able to destroy my wallet when I am done using it, so that I don’t have an empty wallet I don’t need) - not immutable

Purses (already done)

• Create purse (As a user, I want to be able to create a purse so that I can send tokens to another user)

• Put tokens in a purse (As a user, I want to be able to put tokens in a purse so that I can send it to another user)

• Send purse (As a user, I want to be able to send a purse to another user so that I can pay for goods/services rendered)

• Receive purse (As a user, I want to be able to receive a purse from another user so that I can receive tokens for goods/services rendered)

• Remove tokens from a purse (As a user, I want to be able to remove tokens from a purse to put in my wallet so that I can get paid for goods/services rendered)

• Document Object Capabilities approach

• Destroy purse (As a user, I want to be able to destroy a purse once it has finished the end to end transaction from one user to another, so that I don’t lose track of my empty purses)

Rent / Storage (Rent is a nice to have)

• Store transaction data (As a user, I want to be able to store transaction data on the blockchain so that it is available and accessible to users)

• Pay rent on transaction data (As a user, I want to pay rent for my transaction data so that it stays available and accessible to users) [Nice to Have]

• Store non-transaction data (As a user, I want to be able to store non-transaction data on the blockchain so that it is available and accessible to users)

• Pay rent on non-transaction data (As a user, I want to pay rent for my non-transaction data so that it stays available and accessible to users)

• Delete transaction/non-transaction data (As a user, I want to be able to delete my data from the blockchain so that no user has access to it any more)

• Copy data (As a user, I want to be able to copy my data from the blockchain so that I don’t have to pay rent for it any more)

• Rent Due (As a user, I want to be able to determine when rent is due on my stored data)

• Offchain Storage (As a user, I want to securely store my heterogenous data off chain)

• Garbage Collection

Bonding/Unbonding

• Bonding to the network (As a Node Validator, I want to be able to add my stake to the network and be recognized as a validator so I can participate in proof of stake consensus and be eligible to earn rewards (validating).)

• Unbonding from the network (As a Node Validator, I want to be able to retrieve my stake from the network and no longer be recognized a as validator.)

Rewards

• Earning rewards (As a Node Validator, I want to earn rewards by validating blocks on the network)

• Getting paid rewards (As a Node Validator, I want to get paid the rewards I’ve earned so that I can use the tokens I’ve earned)

• Retrieving rewards (As a Node Validator, I want the rewards I’ve earned to go into my wallet so that I can use the tokens I’ve earned)

Slashing

• Slashing to the bone a staked validator (As a Node Validator, I want to be able to slash an operator who isn’t accurately validating, so that they are not able to continue false validations) - Cryptographic evidence of lying

• Partial slash of stake from a staked validator on equivocation (As a System, I want to be able to remove the stake from a staked validator to prevent them from continuing validating)

• Coop gets slash amount and held for a period of reconcilliation (TBD)

• Validators are identifying the equivocation and evidence sent to the other validators

• When the block is finalized (Casper consensus)

• Unbond slashed validator from the network (As a System, I want to be able to remove/unbond a slashed validator from the network to prevent them from being on the network)

• https://rchain.atlassian.net/wiki/spaces/CORE/pages/edit/412024951?draftId=413335578&draftShareId=d783d292-bd37-4b5d-b2e4-87ab1d4f9478&

   

Validating

• Validating transactions (As a Node Validator, I want to be able to validate transactions so that I can earn rewards)

• Software updates (As a Node Validator, I want to be able to update my RChain software without getting slashed)

• Eject Validators who don’t keep up

• Only a validator can propose

API (Joshy, Dan and others working on this and mostly done)

• Deploy (external)

• Propose (internal)

• Fetch list of blocks

• Metrics (CPU, Memory, etc)

Smart Contracts

• Rholang is the smart contract language of the RChain platform

• Rholang evaluation happens in the node via the Rholang interpreter

• Syntax errors (As a dApp developer, I want an error message when there are syntax errors)

• Deploying contracts (As a dApp Developer, I want to be able to propose a contract to the network so that dApp Users can use my smart contract)

• Updating/replacing contracts (As a dApp Developer, I want to be able to update or replace a contract on the network so that dApp Users are using the most recent contract)

• Deleting/removing contracts (As a dApp Developer, I want to be able to delete or otherwise remove a contract so that dApp users can no longer use to the contract)

• Nested contracts (As a dApp Developer, I want a smart contract to be able to call another smart contract so that I can take advantage of another contract’s functionality)

• Contract Definition inside another contract - WIDE (Persisting contracts) - Nice to have (done?)

• K-framework - formal verification

• As a dApp developer who creates a smart contract that I would like to call multiple times, I register it in the registry and I want get back a URI in the deploy response as the end of the registration process.

  • Today getting the URI requires scraping from the log or listening for it on name. Possible because gRPC was listening for the call. Originally intended for debugging.

  • I want to pay Bob. I know his public key, but I don’t have the URI of his wallet.

  • IDEA wallet URI is based on public key

  • As a wallet application I need a way to recover my lost wallet

    • Could be solved if I can predict an unforgeable name

• As a dApp developer, I need to be able to predict the unforgeable name.

  • I want to deploy a contract and pay for it. To do that I need to create a signature over an unforgeable name.

    • Kyle says this is possible.

    • IDEA is the solution to be able to generate unforgeable names offline?

• As a dApp developer, I need documentation for how unforgeable names are generated

  • Current documentation not enough

  • NEED Venus redesign the wallet

  • CONCERN man in the middle attack - create an unforgeable name/URI offline and then deploy contract and start interacting with it, how do I know someone isn’t changing the facts in the middle or that someone else isn't interacting with the contract

• As a dApp developer, I want to get Ethereum-style events and get stdout back in grpc response so that

  • I want to record a log of my CryptoKitties given a range of blockheights.

  • I want to listen on name given a certain depth

  • I want to monitor a contract without operating a node or making a call to a node. I want to subscribe to events via a gRPC response.

    • NEED subscription feature

      • gRPC level subscribe feature is available, it needs to be implemented in RChain

      • IDEA to refactor existing listen for data on name to serve this purpose since it’s pretty close do delivering the functionality

  • Current architecture requires you to have nodes that look at the state (not validating nodes).

    • Read only nodes do this at no cost to watch. Cost is to operate the node.

  • IDEA some sort of channel where everything I send on the channel would return the results and deploy response. A function call.

• As a dApp developer, I want to support binary files as part of deployments

  • CORE-1177

  • IDEA hex to bytes computation

    • CONCERN payment requirement for converting hex to bytes.

      • RSong does this

• As a dApp developer, I need to enhance EVAL and rchain.cloud

  • Use case - we want to deploy a contract and get a return of the evaluation via 1 gRPC call

  • Needs

    • Storage content

    • STDOUT via gRPC call

      • STDOUT is for printing not a gRPC call

    • What the node evaluated (send back what was sent) - used for debugging

  • Discussion to confirm EVAL operates separately from Casper

Identity (RChain Europe?) (Application level, not platform)

• Creating an identity (As a dApp user, I want to create an identity so that I can manage my wallet keys)

• Recovering keys (As a user with a validated identity, I want to be able to use my identity so that I can recover my key)

• Managing identity (As a user, I want to be able to manage who has access to my identity information so that I can keep my information priva