rainblock/rainblock-protocol

☔️🚀Protocol Buffers for Rainblock

Rainblock Protobuf Specification

This package includes protobufs for the RainBlock project.

To run tests, run

$ npm install

To install prototool and git hooks if you are running from a git repository.

$ npm test

Will run the linter with the correct configuration and check that the protobuf can be generated.

If there are linting errors, you can try running:

$ npm run format

Which will attempt to format the file so it passes the linter.

Typescript Usage

This repository automatically generates a npm package with typings you can import into your project.

After running

$ npm install @rainblock/protocol

on your project, you can import the protocol definitions, which are usable by libraries such as gRPC, like in the example below:

import { VerifierService, VerifierClient, TransactionRequest, TransactionReply, VerifierStorageService, grpc } from '@rainblock/protocol'

const client = new VerifierClient("localhost:9000", grpc.credentials.createInsecure());
const request = new TransactionRequest();
client.submitTransaction(request, (err, reply: TransactionReply) => {
    if (err) {
        console.error(err);
    } else {
        console.log(reply.getCode());
    }
});

rainblock-protocol's Issues

UpdateMsg operations: Minimal set of changes after executing a block?

Verifier should send a minimal set of update operations for a block of transactions.

For example:

Case-1: If a block contains multiple transactions updating an account's value:
Verifier should send one `ValueChangeOp` corresponding to the updated account

Case-2: If a block contains multiple transactions updating the account's storage:
Verifier should send one `ExecutionOp` reflecting all the `StorageUpdates`

Case-3: If a block contains multiple transactions updating an account's value and 
has one final transaction that deletes the account:
Verifier should send one `DeletionOp`

Case-4: If an account is created and updated by multiple transactions in the same block: 
Verifier should send one create-op corresponding to the updated balance and nonce

And similarly for other operations...

Storage currently assumes that one update operation is sent per account. We need this to reduce the UpdateMsg size and the RPC serialization/deserialization overheads as well.

For supporting this; we need CreateOp to have nonce field and update the verifier accordingly.
Let me know your thoughts @no2chem

verifierStorage protobuf

If an account is deleted and re-created by the transactions within the same block with new code, the UpdateOp is similar to modifying an existing account's code. Is this okay?

// Used for each update to the node's merkle tree.
message UpdateOp {
  bytes account = 1; // 20 bytes, BE account number
  bytes balance = 2; //  32 bytes, BE new balance. May not be present if the balance is unchanged.
  uint32 updates = 3; // Increment by one for each nonce update. May not be present if the nonce is unchanged.
  repeated StorageUpdate storage_update = 4; // Storage updates, if any.
  bytes code = 5; // Code bytes, only applicable for creation of a contract account.
  bool deleted = 6; // Set if the account was deleted. All other fields, if present, are ignored.
}

Also, if the previous account had nonce n; and we delete the account and create a new account with the same address: how will the nonce be set to 0 for the new account if all that the verifier is sending are updates?