tari-project / tari-dan Goto Github PK

Currently, all proposals only use the PayloadId. The payload is distributed via the NewView messages. The problem is that a VN may receive a proposal, but have not yet received the payload via mempool. NewView messages are only sent to the leader of the round, so it would not have received it that way either.

One way to solve this is to send another message to the nodes, but maybe a good solution is to just include the full payload in the first proposal (i.e. when PayloadHeight = 0)

The config file generated when starting the validator node has all the settings from the base layer. These are unnecessary and misleading

Protocol

sequenceDiagram
   Alice->>+Bob: msg_a 
   Bob-->>Alice: Ack(msg_a)

sequenceDiagram
   Alice-->>Bob: delayed msg_b
   Alice->>Bob: ack timeout, resend msg_b
   Bob-->>Alice: Ack(msg_b) (confirmed)
   Bob-->>Alice: delayed Ack(msg_b) (Alice ignores)

Acceptance criteria:

1. Add a state sync RPC method that can stream back the current state required to bootstrap a VN to the shard committee
2. Add a basic unit test for this method.

To reproduce:

1. Register a template on the base layer.

// use tari_template_macros::template;
//
// #[template]
// mod counter {
// pub struct Counter {
// value: u32,
// }
//
// impl Counter {
// pub fn new() -> Self {
// Self { value: 0 }
// }
//
// pub fn value(&self) -> u32 {
// self.value
// }
//
// pub fn increase(&mut self) {
// self.value += 1;
// }
// }
// }

2. Submit an instruction CallFunction <template_address>, new

Expected: transaction is processed
Expected: transaction is removed from mempool
Actual: transaction is still in mempool.

Acceptance criteria:

1. Implement all functions in dan_layer/storage_sqlite/src/sqlite_shard_store_factory.rs

Specificallly, we need:

• VnConfirmationTime (To be applied to base layer scanning)
• validator_node_timeout (To be used to know when to reregister)

Currently, validator node registration UTXOs are not stored.
The validator_nodes table already exists.

File: https://github.com/tari-project/tari-dan/blob/development/README.md needs to be rewritten

When the vn starts up, it starts a web server on port 6000.

It uses the jsonrpc (with javascript) to display stats of the validator node, including:

1. Connections to the network
2. Mempool stats
3. Epoch Manager stats
4. Which committees it is connected to
5. Recent transactions

currently it panics

Submitting a transaction sometimes results in

09:53 ERROR Error while processing new payload (on_next_sync_view): Epoch manager error: No epoch found Epoch(0)

VN should require an explicit initial registration, once registered, it should auto re-register (enabled via configuration)

Acceptance criteria:

1. Start a new VN
2. No registration transaction is submitted
3. Run ./validator_node_cli register
4. Node re-registers once previous registration has expired

Download and store template binary - only http urls need to be supported for now
Blocked by "[base-layer-scanner] detect and store info about code templates on base layer"

Acceptance criteria:

1. the code template service attempts to download the wasm binary from the given http url
2. binary data is stored in a file template_store/[author_public_key]/[binary_hash].wasm
3. the above path should be written to the db record, the contents validated against the sha
4. if valid, the status updated to valid otherwise invalid

Current status: Currently download to sql database, we should abstract wasm template storage from the template manager and use the above file structure.

Urls are in multiaddr form on the base layer e.g /dns4/github.com/tcp/443/http/tari-project/wasm_examples/releases/download/v0.0.6/erc20.wasm (typed as a string because rust multiaddr does not support the entire multiaddr spec (http paths) :/) however this is given as is to reqwest. Multiaddr is preferable because it supports ipfs, p2p links etc.
As a hack for now, we can look for /http and parse the first part as a multiaddr and the second part as a path
fn parse_http_multiaddr(s: &str) -> Result<(Multiaddr, String)>

The memory shard db was useful for unit tests, but it is duplicate code of the sqlite shard transaction.

I suggest removing the memory db and instead using a TempDb like we do in the base layer for unit tests.

This will test more of the functionality instead of testing the mocked memory db.

Note: Each test should create a random temp file and it should be deleted after every test

The base layer scanner stores the height so that it doesn't scan the base layer over and over. It should also save the vns that it scanned, otherwise when it starts again it will not have the data.

See here: https://github.com/tari-project/tari/blob/development/common/src/configuration/bootstrap.rs#L102

Acceptance criteria:

1. Templates marked as pending in the database
2. Start up VN
3. Template downloads are queued for download

This also means we can retry downloads by UPDATE templates SET status='Pending' where status = 'DownloadFailed' and restarting

Currently, if the VN can't connect to the base layer, the process continues, even though it can't function properly.

Expected:
If there is a problem connecting (e.g. bad config, or the base node is not running), the process should exit

Need to wire up the payload processor to the InstructionProcessor

Acceptance criteria:

1. test showing once consensus is reached, the transaction is executed and substates are returned
2. (optional) Substates are persisted

In hotstuff_waiter on_receive_proposal, the vote message is created and signed here:

  let mut vote_msg = VoteMessage::new(*local_node.hash(), local_shard, decision, votes.clone());
                        vote_msg.sign();

However, vote_msg.sign is just a stub right now:

 pub fn sign(&mut self) {
        // TODO: better signature
        self.signature = Some(ValidatorSignature::from_bytes(&[9u8; 32]).unwrap())
    }

This should be implemented and tested.

Acceptance criteria:

1. get_template_registrations is called once and all templates added when catching up on the chain
2. Templates are ingested up to the tip - confirmations (need to add an end_height param)
3. May need to return the height in GetTemplatesReponse

Currently we build the web-ui in the build.rs, and this requires npm to be setup in the environment.
This means that a node environment is required to be setup to build the vn which can be annoying when running the VN from a different shell (like intelij run) leading to confusing build failures.

I suggest rather that we have to manually run npm to build the web-ui to be included in the binary.
There are a few options from here:

1. Let that be that, if you dont build the webui, it will display a blank page/help page.
2. add an optional cli flag --webui-root ./whatever that overrides the content served on the web-ui port.
3. stringhandler: Only run npm if a certain env is set / nodejs is setup
4. Cifko: ignore the error in the build.rs and emit a build warning

no 1. is simpler, we'll have to allow CORS in development because you may want to dev on the web-ui using npm serve
no 2. allows the updated content to be served directly from the VN, making dev easier. But you can serve from a node server anyway so YAGNI

Both are fine for me, but 2 is a feature that needs to be added that may/may not be generally useful.

For production builds, we add the npm build to the process (build script or whatever).

Acceptance criteria:

1. Template fails to download
2. Submit transaction with the failed template hash
3. The validator node does not attempt to run the template and returns an error saying that the template has DownloadFailed status

At the moment, the base node is continually getting asked and erroring with this:
09:43 ERROR BaseNodeService failed to handle local request ChainStorageError(ValueNotFound { entity: "ShardKey", field: "public_key", value: "222f59f59229dda1f3453a143b12eb2947e2217664be1373a85b25d9cb3ab642" })
09:43 ERROR Error Chain storage error: The requested ShardKey was not found via public_key:222f59f59229dda1f3453a143b12eb2947e2217664be1373a85b25d9cb3ab642 in the database

get_code_template(template_id) -> WasmModule
Blocked by "[code-template-service] Download the template binary from the URL"

template_id will likely be the UTXO hash/commmitment but could be any info that is uniquely identifiable and indexable from the public blockchain. A wallet will have to provide the ID when building a transaction involving a template.

Acceptance criteria:

1. Trait that abstracts the mapping between a template hash (from an instruction) to an instance of the template code
2. Implement this trait so that the impl is able to provide templates that have been found on the base layer, downloaded and verified
3. Errors if, the template_id cannot be found and if the template does not have either valid or deprecated status
4. Load the template bytes into the WasmModule type (we may want an abstraction for "anything that can be executed" rather than a WasmModule but WasmModule is fine for now)

https://github.com/cucumber-rs/cucumber

In either case, using cucumber and/or rust integration tests, we'll need some process/instance builder.

let vn1 = ValidatorNode::builder("vn1")...spawn();
let vn2 = ValidatorNode::builder("vn2")..with_seed_peers(..)...spawn();

vn1.jrpc().submit_transaction(....).await?;

Acceptance criteria:

1. Initial boilerplate code for integration testing
2. (optional) a simple test that starts and stops a VN

Possible future work (not required now):

• ability to mock out base layer grpc services
• ability to start up an actual base layer node and/or wallet process
• Macros to quickly spin up and structure networks. E.g network![ Alice, Bob, Carol ]

When starting the validator node, it should use the network specific ports for gRPC when connecting to the base node.

Currently, the leader will send a proposal as soon as it receives the first NewView message. Doing this is risky because it may send out a proposal that is based on a lower justify height than the majority of VNs has. If this is the case, the other VNs will not vote for it and it will fail consensus.

What it should do is store each high_qc received from the NewView messages and only send once it has received n - f

https://docs.rs/include_dir/latest/include_dir/

Currently, the number of hotstuff rounds required are hard coded as '4' in many places. This should be made a consensus constant and can be changed per network

Acceptance criteria:

1. After validator node downloads the wasm binary, it should check the hash that was specified in the base layer
2. If the hash is not valid, then it should be marked "invalid" in the database
3. When a node calls that template, it should fail and not execute any code in the binary

Acceptance criteria:

1. Create the start of a react-bootstrap site (suggestions welcome)
2. Attempt to connect to local JSONrpc port of validator node through well -known port (using the tari dan provider interface)
3. Display validator node public key, mempool state, recent transactions

For me, ideally in typescript, which similar to rust, ends up saving on time spend debugging typos, type mismatches etc IMO generally more maintainable.