dusk-network / consensus Goto Github PK

Summary

Instead of having an additional oneshot channel to sync up both tasks, we should consider deprecating it in favor of more idiomatic and efficient task:abort.

Possible solution design or implementation

• While oneshot chan will be handled on idle event_loop, the approach with task:abort terminates a task on any .await call.
• Removing cancel_chan will simplify context.event_loop so we can keep timeout_at without the additional tokio:select!.

Additional context

Summary

In the direction of having both Golang and Rust implementations working together in one cluster, we should be able to preload the same list of provisioners (so called genesis state provsioners) in rust example node.

Describe the bug
As suggested by @herr-seppia , we should re-format all files with rustfmt.toml, max_width = 80.

Describe the bug
Request, provide and collect a candidate block routines are not currently supported. This makes it impossible to create a winning block on reaching consensus. With this issue we want to support write and read candidate block. In other words,
an example node should:

• Read a block from topics.NewBlock message
• Store the candidate block (mapped by hash) in a simple (in-memory) database
• Read block by hash in Agreement loop

Once these points are done, we'll be able to return the winning block from the agreement loop.

Additional context

Add a short explanation of how SA works, describing the different phases.

Describe the bug
Current codebase uses pk.pk_t().to_bytes() instead of pk.to_bytes()

Describe what you want implemented

Consensus Loop

1. Impl consensus::spin that executes main loop and spawns agreement loop
2. Impl internal message passing between steps
3. Impl event loop with timeout for each step.
4. Impl message handler for each step.
5. Share common logic of message handlers in a trait.
6. Impl Deterministic sortition
7. Impl Provisioner and Committee structures
8. Filter messages by Is(committee)Member
9. Impl am_member
10. Impl an atomic message queue to map messages to round and step.
11. Re-queue any messages from future round/step.
12. Process future messages in each step.
13. Impl an example application that bootstraps a cluster of 5 mocked provisioners, each running its own consensus.
14. Selection: Verify new block msg signature
15. Selection: Verify signature in both reduction messages.
16. Selection: Verify new block candidate
17. Selection: Store candidate block
18. Selection: Send New Block Message
19. Reduction: Send Reduction in async manner.
20. Reduction: Send Agreement message
21. Reduction: Pass message.StepVotesMsg between reductions
22. Reduction: Impl Aggregator struct and CollectVote algo
23. Integrate and dusk_bls12_381_sign library for PublicKey and Raw key
24. Integrate bls.AggregateSig(s.Signature, signature)
25. Benchmark: Deterministic sortition upon 1000 keys

Agreement loop

1. Implement tokio::task that collects both agreement messages and collected_votes (internal) messages.
2. Add support for futures_msgs put/get
3. Implement simple/single-threaded Accumulator
4. Implement Accumulator::accumulate function
5. Implement Agreement verification procedure
6. Implement collect_agreement msg handler
7. Implement collect_votes msg handler
8. Implement thread-safe committee cache shared between agreement and accumulator tokio tasks.

Optimizations

1. Parallelize agreement.Accumulator agreement verifications
2. Implement AggrAgreement message

Fetch candidiate blocks

1. Request candidate block by hash
2. Fetch and validate

Ideas

1. Consider running consensus tasks as OS threads instead of tokio::runtime tasks.
2. Consider running Accumulator work pools as a separate tokio::runtime or spawn_blocking

Describe the bug
Current version of consensus implementation does not support AggrAgreement message. This should be added in order to be compatible with the impl in golang.

Additional context
The testbed (example/testbed) integration test reach consensus without AggrAgreement (due to agreements accumulating), so this issue is not a blocker.

Describe what you want implemented
Add CHANGELOG

Describe "Why" this is needed
To keep track of changes

Describe alternatives you've considered
Not having a changelog

Describe the bug
verify_step_votes algorithm is needed in the verification of block certificate. For now we can expose and use it directly in the block acceptance procedure.

Describe the bug
A trait that defines EST calls (execute_state_transitions, verify_state_transition) should be passed to consensus from outside so that block generator can execute state transition and reductions steps can verify state transition.

Describe the bug
As per the golang impl, consensus (Accumulator) should be capable of verifying agreement messages concurrently or in parallel. By the default, golang impl spawns 4 workers. This could be achieved by implementing any of the following approaches:

1 Run a separate tokio::runtime with 4 dedicated threads to perform solely agreement message verification.
2. Use tokio::spawn_blocking() or native thread::spawn()
3. Use data-parallelism library (e.g Rayon)

NB. For options 2 and 3, we'll need to bridge with sync code.

To Reproduce
Running consensus with 64 provisioners (respectively more agreement messages exchanged) would create a perf bottleneck in the process of agreements verification .

Additional context
With current impl, there is a noticeable consensus perf downgrade when running testbed with 8 or more provisioners.

Describe the bug
The implementations of PartialOrd and Ord of PublicKey wrapper are based on the CPU-intensive dusk_bls12_381_sign::PublicKey::pk_t()::to_bytes(). This was spotted as a bottleneck on CPU profiling. To avoid frequent serialization into compressed form (to_bytes) , a cache field should be used instead.

Describe what kind of specification you want to have created
Repository has been moved into rusk/consensus

Remove anything and update the README accordingly

Summary

Enable CI checks

DUSK value in dusk-blockchain sortition code was mistakenly set to 100 000 000 instead of 1 000 000 000.

It is likely the same occurs in this repo, since the two clients reached consensus.

Summary

As per the implementation of GetCandidate procedure in dusk-network/rusk#889, get_candidate_block_by_hash should be now incorporated and used in first reduction step.

get_candidate_block_by_hash should be called asynchronously as it may need to wait for a missing candidate block to be retrieved from network peers. Due to that MessageHandler::collect should be turned into an async method.

Summary

The README file should cover/depict:

Implementation details:

• HowTo set-up and run a consensus instance
• Consensus static/dynamic config params
• Usage of test-harness/example node
• Design details of consensus implementation/diagrams.
• Overall component diagram of the example node

Additional Context

Later on, we should add a reference to Consensus protocol whitepaper.

Summary

Adapt to dusk-network/dusk-blockchain#1527

Describe the bug
Once consensus has been running smoothly and producing blocks for a few rounds, some of the nodes encounter the VoteSetTooSmall error. This problem is only observed after activating block re-broadcast on the node side.

Captured traces:

{"timestamp":"2023-03-31T09:29","level":"ERROR","message":"VoteSetTooSmall","target":"dusk_consensus::agreement::accumulator","span":{"name":"acc_task"},"spans":[{"pubkey":"ada282d4c9e0ccf9","round":1,"name":"agr_task"},{"name
":"acc_task"}]}

{"timestamp":"2023-03-31T09:29","level":"ERROR","message":"VoteSetTooSmall","target":"dusk_consensus::agreement::accumulator","span":{"name":"acc_task"},"spans":[{"pubkey":"9599c75362222663","round":1,"name":"agr_task"},{"name
":"acc_task"}]}

To Reproduce

1. Run a network of 3 provisioners
2. Enable block re-broadcast in chain component

Summary

An executable that integrates both consensus and kadcast libraries should be built as an example node. This node binary should accept a CLI param of a provisioner unique ID.

Due to the lack of a genesis block, on start-up the example node is supposed to generate up to N provisioners (also a CLI param) with a deterministic seeds (from 0 to N).

Additionally, this task should provide a Makefile target/Bash script that can set up and run a test-harness of N nodes. Eventually, this could turn into github action and serve as an end-to-end/system test. This bash script may also deprecate current single-process testbed.

Additional context

The ultimate output of this effort should be an example project that dusk-node(Rust) can be based on.

Describe the bug
Rust test-harness driven by the (example) node has demonstrated stable results on any run. It reaches quorum/consensus up to 1000 rounds without any issues. However this test is completely isolated from the ongoing Devnet/Testnet. As an ultimate test-scenario, an example node should join the golang test-harness cluster and participate in consensus correctly.

In order to confirm this has been achieved, we should ensure that the rust-node impl can:

1. encode/decode any consensus wire messages
2. compute same sortition result ( #30 is a precondition)
3. send and collect votes correctly (Aggregator state)
4. send and collect agreements correctly (Accumulator state)
5. send and collect AggrAgreement

This issue should also address any bugs found on testing all 5 checks.

Additional context
TBD

Describe the bug
For better maintenance and interoperability, the wire message structures have been moved into node-data crate together with AsyncQueue and ConsensusPublicKey.

Full list of structs to substitute:

• node_data::message::{Message, Header, Metadata, Topics } instead of crate::messages::{payload, Header, Topics Message};
• node_data::message::payload* instead of crate::messages::payload::*
• AsyncQueue instead of crate::util::pending_queue::PendingQueue
• node_data::bls::PublicKey instead of ConsensusPublicKey

Summary

Replace Block and Transaction struct with definitions from node-common crate.

Additional context

💡 Depends on dusk-network/rusk#834

Describe the bug
None of the steps process timeout event.

			// in case of timeout we increase the timeout and that's it
			p.IncreaseTimeout(r.Round)

Summary

Current serialization of consensus messages (NewBlock, Reduction, Agreement) does not match fully the serialization of the dusk wire protocol. This issue should also address #21 (comment)

Additional context

A discussion should be open about if we should update the dusk wire protocol having in mind that it is not fully efficient (e.g fixed-size fields like signature are serialized like variable-size fields)

Describe the bug
On receiving a valid future block, the synchronizer should be able to cancel a running consensus instance.

Summary

pub trait Database should be turned into async_trait to be used in async code properly.