🚧 | Y3: Efficient subnet consensus protocols

consensus-shipyard / consensuslab

The go-to place for scalable decentralised consensus research

66 stars 3 forks source link

🚧 | Y3: Efficient subnet consensus protocols #9

Closed jsoares closed 2 years ago

jsoares commented 2 years ago

Description

Our goal is to design and implement scalable, efficient consensus protocols for subnets (i.e. anything below the top-level Filecoin consensus). This should enable secure, low-latency operation up to ~500 nodes per subnet.

These protocols will be integrated with Eudico, the research clone of the Lotus Filecoin client, supporting a hierarchy of subnets, each running its own instance of a consensus protocol.

To achieve our, we develop Mir, a framework for implementing distributed protocols. The first protocol to be implemented is ISS, a multi-leader BFT-style consensus protocol, in conjunction with Narwhal, a state-of-the-art mempool implementation enabling sale-out throughput.

The design should be, however, general enough, and its implementation sufficiently modular, to make it easy to implement various different consensus protocols and select any of them for any particular subnet deployment.

Scope

Specify mid-tear and leaf-level consensus
Implement a modular and scalable (up to low hundred of nodes) consensus solution
Integrate the solution with the the (experimental) Filecoin client Eudico.

Resources

Mir distributed protocol implementation framework
ISS consensus protocol implementation (in progress)
Incremental Design of Eudico's Ordering Layer (describes high-level ideas and logical abstractions)
Implementation of Eudico’s Ordering Layer
Testing and verification plan (By @dnkolegov , WIP)

Papers

Talks

soon™️

Demos

2022-04-07, MirBFT

2022-06-02, Crash failures in Mir and its integration with Eudico

2022-08-12, Reproducible Integration Testing in Mir

2022-08-12, Taking Pseudocode To An Implementation With Mir Framework

2022-09-01, Reconfigurable SMR with Mir

2022-09-01, Dynamically adding new nodes to Eudico with Mir

jsoares commented 2 years ago

2022-02-21 meeting notes

Discussion with Alfonso and Denis around implementation approach. Synchronised on the state of each part of the project. Tendermint almost done. Next upcoming chunk is on the Eudico side (~2 weeks). In parallel, we’ll look into implementing MirBFT stub.
We’ll also look into how ISS works and identify the key parts of the ISS protocol that need to be implemented to have a working prototype.
- Marko: We should come up with roadmap for this
  - Timeline: With testnet in Q4, what can we expect to have ready in time?
    - Having stable interface is the priority.
    - Estimating effort and timeline is next step — aiming to have someone by Monday. Let’s try for monthly milestones and zero-mean error.
Narwhal: first focus on the framework, interface and requirements for usage. For now, plan to use default mempool. Alfonso will be supporting on Eudico side. Immediate AIs: share ISS paper with Denis and go through MirBFT.
- Is it clear that Narwahl can be added on top of Mir-BFT? Is there a unifying architecture?
  - Narwhal and MirBFT are not interchangeable. Narwhal can use MirBFT as a blackbox ordering service. The architecture should be modular, with MirBFT and Narwhal as specific instances.
  - We may lose some specific properties/advantages in favour of generality.
How should we do state transfer work in Eudico?
- Have a snapshot of the state tree. Unclear how efficient it will be. This is synchronised to a specific epoch and consistent across nodes. We can also add reconfiguration messages — these can be part of a block and be part of the total order.

jsoares commented 2 years ago

2022-02-28

✋ Attendees

@matejpavlovic
@dnkolegov
@adlrocha
@jsoares
@LefKok
@vukolic

📣 Updates

Discussing architecture and making a list of to-do items to make MirBFT a consensus protocol for Eudico
First milestone define
- M1: minimal demoable implementation
  - Eudico client-service interface (~ that for Tendermint) [Denis, 3 wks]
  - Implementation of PBFT subprotocol in ISS [Matej, 3 wks]
  - State garbage collection and transfer [4 wks]
  - Prepare demo [1 day]

🧵 Discussion

Did we consider alternatives to PBFT?
- Alternatives considered but PBFT is the most settled and general. Fastest to implement. Good performance in previous experiments.
- We can try others in parallel but preference for the team to sart there.
Timeline for the overall project
- End of Q3 realistic for testnet
- Only critical items after M1 is
  - Reconfiguration
  - Persistent request store
  - Persistent write-ahead log (trickier)
- Let's try to organise the follow-up milestones
Matej + Denis + Sergey sounds like full staffing; shouldn't need any more capacity. Some parts are not highly parallelisable.
We may be able to reuse testing framework from Lotus/Eudico instead of spending a lot of dev cycles on it

🎯 Up next

Define timeline for M1 (start and end date)
Define high-level milestones for the rest of the project
Organise meeting on testing tools and invite Marko

jsoares commented 2 years ago

2022-03-07

✋ Attendees

@adlrocha
@dnkolegov
@jsoares
@matejpavlovic
@vukolic

📣 Updates

Refined Project Milestones
- Assigned tasks by priority to different milestones
- Separated parallelizable best-effort tasks
Added estimated timeline for Milestone #1 (P0)
Wrote internship proposal

🧵 Discussion

Applicability of VDFs to PBFT vs. other protocols
Internship proposal comments?
Robust leader election
- Want to verify an idea/assumption that PBFT could easily be made robust in this sense.

🎯 Up next

Continue implementing PBFT sub-protocol
Check alignment of interests with Srivatsan
Potentially submit Hyperledger mentorship proposal (deadline on Wed)
@jsoares to add milestones to roadmap

jsoares commented 2 years ago

2022-03-14

✋ Attendees

@adlrocha
@dnkolegov
@jsoares
@matejpavlovic
@vukolic

📣 Updates

Good case of PBFT works.
Basic mircat demonstrable with PBFT.
Camera-ready for ISS paper almost ready.
mircat as a subproject.

🧵 Discussion

Would a demo video showing basic usage of mirbft (using a sample chat application) be useful? Another video with failures could follow when PBFT view change is implemented.
- Let's go with short recordings for intermediate progress, and plan a demo on the April demo day.
- Look into visualisation tooling for traces. Consider a dev shop.
  - Jorge having regrets about us not having joined the hyperledger mentorship programme

🎯 Up next

Consolidate documentation and high-level project description for broader audiences.
Implement PBFT view change.
Focus on the mirbft interface
Create a GitHub issue for mirbft Eudico interface

jsoares commented 2 years ago

2022-03-21

✋ Attendees

@adlrocha
@dnkolegov
@jsoares
@LefKok
@matejpavlovic
@vukolic

📣 Updates

Started implementing PBFT view change
Consolidated big part of the documentation for MirBFT
Updated some related issues on ConsensusLab GitHub, added a few sub-issues

🧵 Discussion

New target date for MirBFT-Eudico interface 3 weeks into April: OK with Denis?
- Denis: Yes

🎯 Up next

Continue working on PBFT view change implementation
Maybe demo (if time allows)

jsoares commented 2 years ago

2022-03-28

✋ Attendees

@dnkolegov
@jsoares
@matejpavlovic
@vukolic

📣 Updates

Suggested project for Sergey: State transfer in MirBFT.
More code on PBFT view change.

🧵 Discussion

Make #90 ISS with chain quality a discussion?
- It's now a discussion -- let's document today's conversation and other thoughts as they come along.
Usage of VRFs for bucket assignment.
Value proposition of Narwhal vs MirBFT
- And how they go hand-in-hand
- Should we have a sprint to work out the best direction? Start async discussion; highest priority.
  - Denis can still work on MirBFT integration after itests; meeting on Wednesday
- Task protocol also at top of mind; simple, co-designed with Narwhal, something to know about when having this discussion
  - Ideas from Hedera/hashgraph?

🎯 Up next

PBFT View change.
MirBFT usage demo for 7 April.

matejpavlovic commented 2 years ago

2022-04-11

(Updated by @matejpavlovic 2022-04-12)

✋ Attendees

@adlrocha
@dnkolegov
@LefKok
@matejpavlovic
@sergefdrv
@vukolic

📣 Updates

Narwhal and ISS at EuroSys
New discussions around deduplication in consensus protocols.
Denis and Sergey starting this week! 🥳

🧵 Discussion

Implementation Framework Name

Currently MirBFT - carries historical baggage. Let's rename to

GoNode

Initial idea was Node.go (like Node.js), which would have fit even better to the abstraction it provides, but Node.js is a registered trademark. For now the repository lives at https://github.com/matejpavlovic/go-node and will be populated with code soon.

Consensus Protocol

Given recent research results (Narwhal, Tusk, Bullshark, etc.) and discussions,

it seems like we can have 1 out of 2:
- request deduplication and
- resistance to a mobile adversary (DoS resistance).
The long-term solution will almost surely involve a DAG.

Thus, it is worth revisiting the current plan for consensus implementation. The long-term solution will involve a

Current path:
- Strategy:
  - Implement and use GoNode.
  - Within GoNode, implement the ISS protocol (including deduplication).
  - Use a simple mempool approach (hook Eudico's mempool to GoNode using some adapter code) and add Narwhal much later.
- Pros:
  - Probably the simplest and fastest path to an MVP.
  - @matejpavlovic has experience with ISS.
  - Verified with the ISS PoC.
  - Good latency in the good case
- Cons:
  - Vulnerability to a mobile adversary that would need to be resolved later.
  - Limited throughput with failures / asynchrony.
  - Discussion on request duplication hints that deduplication inside ISS might be a dead end.
DAG-based path (a)
- Strategy:
  - Implement and use the GoNode framework.
  - Use GoNode, use duplicated ISS (dISS): Boils down to simple multiplexing of PBFT instances.
  - Implement the Narwhal DAG (ideally also with GoNode).
  - Combine dISS and Narwhal.
  - Optimistic Narwhal deduplication (can be postponed).
- Pros:
  - A more general design, including the DAG as an abstraction from the start.
  - Simplifies ISS implementation (by reducing it to dISS).
  - Readiness for a wider family of DAG-based consensus protocols.
  - Resistance to a mobile adversary (DoS).
  - Probably better throughput under failures/asynchrony.
- Cons:
  - Probably marginally higher latency than current path.
  - No PoC for exactly this protocol (although Narwhal-HotStuff probably applies).
  - Requires altering current roadmap (but just slightly - moving Narwhal to the front of the queue).
DAG-based path (b)
- Strategy:
  - Like DAG-based path (a), but also exchange dISS for a different protocol (e.g. Tusk or Bullshark)
- Pros:
  - Potentially better latency than (a)
- Cons:
  - Comes close to "from-scratch" solution with big investment in new protocols and uncertain result.
Everything-from-scratch path
- Strategy:
  - Deep dive into the latest research results.
  - Redesign everything from scratch without regard on what we already have.
- Pros:
  - No bias by current state
- Cons:
  - Big overhead of starting from scratch with a result that might not be better than other two approaches

Conclusion:

Use Eudico's gossip-based mempool for obtaining TXs
Implement a simple availability layer where each node constructs blocks from the received requests and obtains availability certificates
- This will be later extended to Narwhal
Each node proposes the availability certificates to the consensus layer
Implement a simple consensus layer that multiplexes PBFT instances without deduplication (for DoS resistance)
Deliver the output of the consensus layer back to Eudico

🎯 Up next

@dnkolegov
@matejpavlovic
- Study DAG-Rider and Bullshark in more detail
- Kick off work with Sergey
@sergefdrv

vukolic commented 2 years ago

Would we need "RustNode" as well?

adlrocha commented 2 years ago

From complete ignorance, @matejpavlovic, how does Mir-BFT relates to Node.js? (I am just wary of this kind of generic names :smile: ). It makes SEO and general discoverability harder.

vukolic commented 2 years ago

+1 I am not a huge fan of the name proposal

dnkolegov commented 2 years ago

Why Node? Node-go or go-node says that "Node" is implemented in Go, but what Node is, and how does it relate to BFT?

If we are talking about names:

uBFT - Universal BFT or any other xBFT, and then ubft-go,...
orbitox

matejpavlovic commented 2 years ago

Proposing the initial draft of the design document for incremental implementation of Eudico's ordering layer. Comments welcome! https://hackmd.io/@matejpavlovic/ryd53ZP4c

sergefdrv commented 2 years ago

initial draft of the design document for incremental implementation of Eudico's ordering layer

I left some comments

matejpavlovic commented 2 years ago

2022-04-21

✋ Attendees

@dnkolegov
@jsoares
@matejpavlovic
@sergefdrv
@vukolic

📣 Updates

Wrote design document on the architecture and modularization of Eudico's ordering layer.
Started documenting Mir architecture decisions with ADRs
Updated roadmap on CL GitHub

🧵 Discussion

Separate Slack channel for Mir implementation?
- mir-impl or #mir-implementation
- Public if not polluting the Filecoin Slack space, otherwise private
We agree on the proposed high-level design
- This is not the detailed implementation architecture
We will start by implementing the first simple variant algorithm-wise and add all necessary algorithm-independent features (reconfiguration, restarts, etc.) before evolving the algorithms

🎯 Up next

Continue implementation
@matejpavlovic to devise a more concrete implementation architecture

matejpavlovic commented 2 years ago

2022-04-25

✋ Attendees

@dnkolegov
@matejpavlovic
@sergefdrv

📣 Updates

Updating design document
Writing implementation document
Started documenting Mir architecture decisions with ADRs
Updated roadmap on CL GitHub
Bug fixing
The initial Eudico and Mir integration is in review
Added app snapshot hashes in checkpoint implementation of ISS

🧵 Discussion

Persistence of Mempool
- TX mempool stays responsible for persisting of payloads
- Whenever the Availability layer receives a TX hash, it can count on the corresponding payload to be written in persistent storage
Deployment and static configuration of Eudico nodes
- Take the simplest approach to statically configure the deployment
- Node IDs don't need to correspond to anything in particular (no need for a node ID to be a wallet address, for example)
Mining and "proposers" of blocks - incentives in BFT consensus
- Introduce mechanism for general "contribution" to the 2nd (MVP) milestone
- Have a static "dummy" address in the Miner field of generated Eudico blocks.

🎯 Up next

Continue implementation
Discuss with Marko and Alfonso: Miners in Filecoin, Eudico and Mir. Does the conception of Miner exist in Filecoin version with a BFT-type consensus algorithm?

matejpavlovic commented 2 years ago

2022-05-02

✋ Attendees

@adlrocha
@dnkolegov
@LefKok
@matejpavlovic
@sergefdrv
@vukolic

📣 Updates

@matejpavlovic:
- Architecture of consensus layer implementation
- ADR proposal for time abstraction in Mir
- Mir improvements: fix race in test deployment, fix GitHub Actions, fix shutdown bug, add linter check as GitHub Action
- Still implementing PBFT view change
@sergefdrv:
- Resolved Basic ISS checkpoints - Create certified checkpoints and produce debug output when they are created
@dnkolegov:
- Launching Mir in subnet via rootnet
- Bug fixing

🧵 Discussion

@matejpavlovic: Time abstraction
- Example of timer usage to ADR
@matejpavlovic: Sergey's launchpad
- No for the moment
MV: do we have upcoming (May) milestones defined? How will we evaluate progress against our goals?
- https://github.com/protocol/ConsensusLab/issues/62
DK: Eudico miner within Mir: at present we can't know who has proposed (mined) a block to propogate this to Filecoin blocks
- DK to open an issue in Mir around this
  - https://github.com/filecoin-project/mir/issues/43
- Explicitly ping Alfonso if we need his input

🎯 Up next

@matejpavlovic:
- Implement PBFT view change
- Reach consensus on technical decisions
- Continue improving Mir
@sergefdrv:
- Open discussion on Mir framework architecture concerns
- Feedback on Implementation of Eudico’s Ordering Layer and Time abstraction in Mir
- Work on ISS state garbage collection

matejpavlovic commented 2 years ago

2022-05-09

✋ Attendees

@adlrocha
@dnkolegov
~~@jsoares~~
@LefKok
@matejpavlovic
@sergefdrv
@vukolic

📣 Updates

@sergefdrv
- Discussion on Mir framework architecture
- Working on ISS state garbage collection
@matejpavlovic
- Discussion on Mir framework architecture
- Improving Mir
- Implementing PBFT view change
- Internship with Andrei for implementing Narwhal in Mir
@dnkolegov
- I was working on intergration Eudico with Mir
  - bug fixing
  - refactoring
- Now we can define a miner for Filecoin blocks

🧵 Discussion

Mir architecture
- Try using the current event-based architecture and see if we need to work a lot against it.

🎯 Up next

@matejpavlovic
- Continue implementing PBFT and Mir
- Interface to Eudico definition
@sergefdrv
- Finish ISS state garbage collection
- Work on ISS state transfer

matejpavlovic commented 2 years ago

2022-05-16

✋ Attendees

@adlrocha
@dnkolegov:
@jsoares
@LefKok
@matejpavlovic
@sergefdrv
@vukolic

📣 Updates

@dnkolegov
- Eudico demos
- Eudico and Mir integration
- Improving Eudico
- Initial test concept
- Discussion with Matej on the Mir design and the next task for me
@matejpavlovic
- Implemented PBFT view change and a debugger for Mir
- Drafted list of things to implement for ordering layer
- Started designing Eudico's ordering layer interface
@sergefdrv
- Implemented state garbage collection
- Fixed BFT quorum size calculation

🧵 Discussion

How will we do state transfer?
- Plans for week of 16/05: grab serialised state and transfer as it is; trivial app example, might not work for Eudico.
- We'll have checkpoints; in the long run, the state transfer within Mir will likely be the same thing. Then we can transfer overall state in Eudico.
- Mir is there to do ordering, not deal with full state payload.
Y3-M3 plans
- Will need some input from Alfonso in the next few days
- Early focus on perf benchmarks
Demo on 2 Jun?
- We can demo Denis' previous work + failure
- Benchmarks not likely

🎯 Up next

@dnkolegov:
- Multisig collector
@matejpavlovic
- Converge on a spec for Eudico's ordering layer interface
- Specify concrete issues for the Y3-M3 milestone (ordering layer MVP)
- Present Mir debugger and show how it is used
@sergefdrv
- Test memory consumption with/without checkpoint garbage collection
- Work on state transfer

jsoares commented 2 years ago

2022-05-23

✋ Attendees

@dnkolegov
@jsoares
@LefKok
@matejpavlovic
@sergefdrv
@vukolic

📣 Updates

@matejpavlovic
- Outlined todos and next steps
- Ordering protocol interface (with the team)
- Presentation of mircat debugger
- Timer module for Mir
- Will be busy with SRDS reviews (deadline on Thu)
@sergefdrv
- Fixed memory leak in ISS
- Added simple memory footprint benchmark in Mir
- Fixed transitioning into new epoch in ISS
- Y3 discussions with the team (this and this)
- Implemented state transfer in ISS
@dnkolegov
- Discussed new Eudico Ordering Layer Interface
- Found and fixed several bugs related to data races in Eudico
- Fixed Eudico's CI pipeline

🧵 Discussion

@jsoares: Where are we on finalising M2? Is this complete with #68?
- Yes, will close on merge
Refine M3 goal

🎯 Up next

@dnkolegov
- Implementing new Eudico Ordering Layer Interface
@sergefdrv
- Come up with testing strategy for Mir/ISS and start implementing it
@matejpavlovic
- Refine timing estimates for M3 plan
- Review SRDS papers

matejpavlovic commented 2 years ago

2022-05-30

✋ Attendees

@adlrocha
@dnkolegov
@jsoares
@matejpavlovic
@sergefdrv
@vukolic

📣 Updates

Denis:
- Worked on Eudico ordering interface (PR)
- Expanded itests for Mir consensus: added tests with two nodes
- Investigated how Eudico works
- Updated the CI config to fix issues with Mir repo
- Intriduced SyncBlock funtion
@sergefdrv
- Learning Filecoin spec
- Draft of Mir Framework Test Strategy
- Enabled LGTM code analyzer for Mir
- Added badges to Mir's ReadMe: LGTM, GitHub CI, Go Reference, Go Report Card
@matejpavlovic
- Refined schedule for M3
- Proposal for Mir Generalization

🧵 Discussion

Addressing errors/warnings reported by code static analysis (linter, LGTM, GH Security)
@matejpavlovic : Dissemination of delivered blocks (Denis' hack) - @adlrocha is it viable?
How does PoS relate to BFT? Do we implement any incentive mechanism?
- PoS is a generalization of BFT, using different voting powers for different nodes.
- The ordering layer gets this data from the outside (power table), no need to figure it out itself.
How does HC work? Who creates subnets and how?
- There is no succinct document describing it yet.
- With the new FVM update, the filecoin will support creating subnets, each of them potentially using (an instance of) the BFT ordering layer.
- The state of the subnet periodically writes its checkpoint to the parent.
@matejpavlovic: Demo day - who shows what? Options:
- @matejpavlovic shows demo chat app with a node crashing
- @dnkolegov shows integration of mir into Eudico
  - with a node crashing (if possible)
  - without a node crashing

🎯 Up next

@sergefdrv
- Discuss and finalize Mir testing strategy
- Start improving testing of Mir
@matejpavlovic
- Polish BFT ordering interface
- Pseudocode using the interface
- Sync with @dnkolegov on demo and pick one option from above

matejpavlovic commented 2 years ago

2022-06-20

✋ Attendees

No zoom call, just async collaboration on the notes.

📣 Updates

@dnkolegov :
- Working on the implementation of Mir cryptographic interface
- Working on the refactoring of the HC code to be able to modify finality threshold and check period parameters that will allow us to decrease the time of tests
@xosmig
- Working on a DSL interface for Mir to fulfil its mission of “writing actual code like it was pseudocode” :)
- Working on the ContextStore abstraction to simplify the workflow of using digital signatures in Mir.
@matejpavlovic
- Major Mir upgrade generalizing the operation of modules.
- Revamped Eudico ordering layer design document. Almost finished, bits of reconfiguration still missing.
- Mir improvement: retaining event logs on GitHub CI test failure
- Big simplification of Mir/ISS: Availability-related parts of ISS removed, as well as client request signature verification. This simplifies the Crypto module interface implemented by @dnkolegov using keys from Eudico.
- Discussion on how to sign protocol messages in the Mir-Eudico integration
@sergefdrv
- Working on integration testing infrastructure for Mir
  - Looked at randomised stateless model checking techniques (inspired by this paper)
  - Looked for a replacement of Ginkgo BDD testing framework (it doesn't seem particularly useful since we don't follow BDD principles)
  - Considered various options from Awesome Go
  - Testify looks like a good option (used it before)
- Lots of code review

🧵 Discussion

Eudico/Lotus libp2p node ID or wallet ID as node/client ID in Mir:
- Discussion on Slack
- Beside using Libp2p ID and its crypto creates some problem from an implementation perspective because it was not designed and implemented for such cases
- Suggestion: to use wallet keys as Mir IDs as we do now
  - Approved on Slack by Alfonso and Matej
- @matejpavlovic: Confirming and approving here as well, will incorporate it (hopefully already tomorrow, Covid permitting) to the ordering layer design document.
- @matejpavlovic: conclusion:
  - Each node (validator) of a subnet is uniquely identified by a wallet address: the address of the node's corresponding wallet in the parent net. I.e., this wallet address serves as the node ID in the subnet. Since the wallet address is directly derived from a key that the node will use to sign subnet ordering protocol messages, no other public key needs to be associated with the node in the subnet.
  - Each node (validator) ID (wallet address) is associated with a libp2p address used to send messages to the node.
  - (Not implemented yet, but part of the design:) Each node (validator) ID is associated with a weight value expressing how much relative voting power the node has in the subnet
  - (Not implemented yet, but part of the design:) In order for the node (validator) to not have to store the private key associated with the wallet address identifying it, each node (validator) ID is also associated with subnet node public key generated specifically for the purpose of verifying agreement protocol messages. The node (validator) will use the corresponding private key for signing.
  - All of the above is saved in the state of the subnet actor (residing in the parent net's state) in some configuration data structure (its exact format and implementation to be determined). How it changes is irrelevant from the subnet's point of view. The subnet just has to react when it changes and adopt the corresponding configuration.
@matejpavlovic:
- @sergefdrv do you want to go ahead with Testify for testing? Why Testify in the end? (Having worked with it is a potential valid reason, if it does the job). What is the main difference to Ginkgo (current patchy tests)?
  - @sergefdrv: Prefer Go native testing and Testify for usability and better integration with Go testing facilities.
    - For example, Testify makes it easy to run specific tests
    - Current Ginkgo tests pollute the output with diagnostic messages. Not the case with Testify and standard Go testing facilities (one can still enable verbose mode when needed)
    - Ginkgo doesn't seem to have native integration with Go's benchmark or fuzz testing facilities
  - @matejpavlovic: Conclusion: Use Testify.
- @sergefdrv are you considering implementing any model checking? I think we should leave that for much later.
  - @sergefdrv: Would just like to have some randomized tests that enforce different order of external events and check that the expected properties (safely and liveness) hold in our implementation rather than full-fledged formal verification of the high-level protocol description

🎯 Up next

@dnkolegov:
- polish Mir's Crypto implementation in Eudico
- finish final threshold/check period refactoring
- find out why itests sometimes panic and fail on the CircleCI node
- start implementing Mir's Transport interface in libp2p
@matejpavlovic
- Finish updating and extending design document, focusing on the sections on reconfiguration and specifying what keys the nodes use and how.
- Express the design described in the design document in go-like pseudocode (that can be used as a skeleton for actual implementation)
- Continue writing Mir improvements
- Review papers for BRAINS'22
@sergefdrv
- Clean up existing Mir test infrastructure
- Implement logical time in integration tests instead of using real timers and clocks. This will speed up testing and give control over event order so that we can make random permutations there.
@xosmig
- Add some tests for the DSL module.
- Merge ContextStore and DSL module to the main branch.
- Start implementing basic building blocks for the future Narwhal implementation.
- Study the Rust implementation of Narwhal.

atonkikh commented 2 years ago

Oh, hi! I'm just QA engineer from another company, I don't mind learning Rust, but can you help with DSL please. Also, do you pay euros?

xosmig commented 2 years ago

@atonkikh oh, sorry, it's because I also sometimes use atonkikh as my nickname. Don't worry, I'll handle the DSL thing :)

matejpavlovic commented 2 years ago

2022-06-27

📣 Updates

@matejpavlovic
- Fix debug mode bug in Mir and a debugger corner case
- Code review of Mir-Eudico crypto integration
- Completed reconfiguration section in the ordering layer design document
- Segment-level checkpoint in ISS
- @sergefdrv
  - Cleaning up existing Mir test infrastructure
  - Code review
    - PBFT instance-level checkpoints
@xosmig
- Merged ContextStore.
- A lot of work on DSL modules:
  - Implement a user-friendly way to manage context using an internal ContextStore.
  - Revisited the design to avoid hacky pointer conversions.
  - Extensively tested and documented.
  - UPD: merged the PR.
- Working on the design draft for dynamically creating and deleting modules in Mir.
- Started working on the availability layer.
@dnkolegov:
- Implemented Mir’s crypto interface
- Working on the new ordering layer

🧵 Discussion

@xosmig: Do we already have some infrastructure to test individual modules? I am thinking how (and if) I should test the BCB implementation
- @matejpavlovic: To my best knowledge, we don’t have that yet. I don’t think testing the BCB implementation should be a priority now though. When Sergey is done with the new testing infrastructure, let’s see if and how that can be leveraged. @sergefdrv do you have anything in that direction in mind?
- @sergefdrv: so far, I'm focused on integration testing, not module-level testing. I think one can write simple tests for individual modules as usual in Go. I would recommend using Testify.
- @xosmig Yes, I did that for dsl modules (just calling ApplyEvents directly and checking the output), but BCB probably needs something more similar to integration tests: we need to run several nodes with other modules and the application being mocked, let the nodes talk to each other while manipulating the network, and check the outcome.

🎯 Up next

@matejpavlovic:
- Finish ISS protocol implementation (mostly message re-tramsmission)
- Update and extend Eudico integration design documents
  - Specify details about (re-)configuration implementation
  - Update Eudico-Mir interface
@sergefdrv
- Continue cleaning up existing Mir test infrastructure
- Implement logical time in integration tests instead of using real timers and clocks. This will speed up testing and give
@xosmig
- Basic availability layer implementation.
- Design draft for dynamic modules, without implementation.
@dnkolegov
- continue working on new Eudico ordering layer
- implement more efficient FIFO mechanism in the Eudico block assembler
- libp2p implementation for Mir

matejpavlovic commented 2 years ago

2022-07-04

📣 Updates

@dnkolegov:
- working on libp2p transport for Mir (Related issue: filecoin-project/mir#81)
@xosmig:
- working on a basic availability layer implementation (Related issue: filecoin-project/mir#79)
@sergefdrv
- Another round of review on PBFT instance-level checkpoints (Related issue: filecoin-project/mir#78)
@matejpavlovic
- Mostly non-Y3 work (HC review and BRAINS conference paper reviews)
- Finalizing PBFT instance-level checkpoints (Related issue: filecoin-project/mir#78)
- Sorting out details transport layer and ordering layer implementation (for discussion summaries, see below). (Related issue: filecoin-project/mir/issues/81)

🧵 Discussion

Libp2p transport for Mir:
- @dnkolegov: @matejpavlovic and I discussed today basic implementation of libp2p transport. Matej's suggestion is to use direct libp2p connections. In essense, that is similar to the current GRPC transport in Mir but with Libp2p. @adlrocha are you fine with that?
- @matejpavlovic: In essence, the transport layer needs to provide authenticated point-to-point messaging. Using gossipsub is not desired for BFT-style consensus, since 1) not all messages need to be send to all nodes and 2) gossip latency is too high for most messages in BFT-style protocols.
- @matejpavlovic: Aggregating from Comments: It seems mostly like a question of performance. Unless there is a really big performance difference, let's stick to one networking stack.
- @matejpavlovic: I'd say we go for libp2p-based transport and once we have time at a later point, experiment with alternatives if we believe we can get a substantial performance gain.
Details on Eudico’s ordering layer implementation
- @xosmig: Last week, @matejpavlovic and I discussed the architecture of Eudico’s ordering Layer and came to a conclusion that, in order to avoid replicating the mempool structure in the availability layer module, the interface between the two should be pull-oriented (the availability layer asks for new blocks) rather than push-oriented (the mempool pushes new blocks/transactions to the availability layer). The main problem with the push-oriented interface was that the mempool could push new transactions at a faster rate than the availability layer could process them. Then we would need to include some buffers and non-trivial strategies for selecting and dropping transactions in the availability layer. On the other hand, pull-based architecture allows to encapsulate all such logic in the mempool module.
- @xosmig: Also, we agreed to merge most of the functionality of batch store into the availability layer due to a high coupling between the functionalities of the two.
  - @matejpavlovic: Will update the design docs accordingly (see "Up Next" below)
- @xosmig: Now I have a similar concern about the interface between the availability layer (composing and distributing TX batches for ordering, e.g. Narwhal) and the consensus layer: should the consensus layer also request (pull) blocks from the availability layer or should the availability layer push new blocks to the consensus layer?
  - There are some issues with both approaches:
    - Push-based: same as before, availability layer can go too fast or too slow.
    - Pull-based: implemented naively, may add extra latency.
      - It can be addressed if the availability layer works “one block in advance”. However, then there may be an issue with “recency” of the blocks (in case the consensus layer is rather slow).
  - @matejpavlovic:
    1. I think this can be addressed by making the Mir module that is emitting events representing the batches for ordering an ActiveModule. That way, if the consensus module is too slow to process them, the Mir implementation will temporarily stop reading new batches from the availability layer.
      - Comment discussion summary: This is a lower-level mechanism to protecting from going out of memory. Let's not use it for protocol-level flow control.
    2. This problem might actually happen to be prevented at a higher level. Given that the system works in epochs (between which it may reconfigure), it might be better to make even the availability layer only produce a finite number of batches per epoch. And since starting new epochs depends on the progress of the consensus protocol, we get an implicit flow control mechanism.
  - @xosmig: a few advantages of the pull-based model (with the optimization of working “one block in advance”):
    - lower coupling, cleaner interfaces (details like “epochs” don't “leak” into the availability layer implementation);
    - I think it may work nicer in combination with a more advanced availability layer like Narwhal because, in case of Narwhal, we probably do want it to go as fast as possible, but sometimes the consensus layer needs to get the latest tip of the dag and commit it (it would be able to do so through the request-response mechanism).
    - The problem of “recency” of blocks in case of slow consensus is less severe, albeit still present. (i.e., the delay between the creation of a block and the time it is proposed is smaller).
A small question about Filecoin:
- @xosmig: does the notion of a "valid transaction" depend on the state of the blockchain? Can / should we start working on a new block before deciding the previous one?
- @matejpavlovic: While we could, in the future, support some "external validation" (informally discussed few times, last time during Consensus Factory), I would not go as far as requiring "closed-loop" block processing. For now (i.e. for the MVP) let's just consider everything that makes it in the mempool as valid (from the point of view of the ordering layer).
- @xosmig ok, noted, thanks.
Consensus proofs:
- @sergefdrv: The HC spec mentiones: Subnets can run any consensus algorithm of their choosing, provided it can meet a defined interface, and they can determine the consensus proofs they want to include for light clients. How do we plan to implement the consensus proofs in Mir/ISS?
- @matejpavlovic: Currently we do not provide an explicit interface for "consensus proofs" (not sure whether and where one is defined for HC. @adlrocha?). But principally, the checkpoint certificates produced by the consensus implementation can serve as proofs, as they are signed by a quorum of the validators.
  - @sergefdrv:
    - It is not quite clear what granularity is requered for the consensus proofs. One natural answer would be: per block, another: per subnet checkpoint. @adlrocha, what do you think?
    - @matejpavlovic, if it is per-block then how do we generate such proofs if we reassemble batched into block at the end of the ordering process?
  - @matejpavlovic: Indeed, if we wanted such a proof for every block, that could be inconvenient to implement, since Eudico blocks don't necessarily correspond to Mir batches.
    - @sergefdrv: Neither the HC checkpoints seem to correspond to the ISS checkpoints.
  - @xosmig: it is always possible to implement a lightweight external gadget that collects >2/3 signatures under a statement "the k-th block's hash is 0x...".
    - @sergefdrv: @xosmig, yep, I think it is easier to generate finality proofs outside, since doing so as a part of consensus implementation might be difficult (think about normal case vs. view changes etc.)

🎯 Up next

@xosmig
- Basic availability layer implementation.
- Design draft for dynamic modules, without implementation.
@dnkolegov:
- working on libp2p transport for Mir
@matejpavlovic:
- Update design documents based on latest discussions.
- Define details and data structures for membership and reconfiguration.

matejpavlovic commented 2 years ago

2022-07-11

📣 Updates

@dnkolegov:
- working on libp2p transport for Mir
  - The initial version is ready, it is very simple and written in the gRPC transport style
  - the gRPC transport will be used for testing purposes
@sergefdrv
- Keep working on logical time in integration tests (in my dirty wip branch)
  - Sketched logical time simulation interface that should work for Mir
  - Defined abstract time implementation to use in timer module
@matejpavlovic
- Updated Eudico ordering design document, added new section on Merit (block rewards)
- Finished basic consensus implementation
- Updated tracking GH issue.
  - 2 sub-tasks marked closed (Interface draft and Consensus layer).
  - Mempool and Transport almost finished (by @dnkolegov), only need review and a bit of boilerplate around them.
  - Availability layer prototype (by @xosmig) implemented, only requires review and integration.
  - Testing being worked on by @sergefdrv.
  - Lef to tackle: Performance evaluation and Reconfiguration (State manager)
@xosmig
- Finished the implementation of the availability layer prototype.
- Summarized design challenges and potential solutions for the dynamic modules in Mir.
- Removed hardcoded dependencies of the Mir core on ISS.
- Implemented a protoc plugin to generate more generic-friendly code and simplified the dsl module implementation using it.
- In parallel, exploring different directions to further improve Mir:
  - Playing around with the protoc plugin to maybe generate all the boilerplate associated with programming on Mir.
  - Working on the concept of “submodules” as a simpler alternative to “dynamic modules”.

🧵 Discussion

@dnkolegov: @adlrocha could you review Mir's libp2p transport or recommend someone from the libp2p team for that?
- @dnkolegov to ping @adlrocha when there is code to review.
@matejpavlovic: A few questions on the testing framework. Mostly for @sergefdrv.

🎯 Up next

@dnkolegov:
- integration Eudico with Mir's libp2p transport
- adopting libp2p transport in the Mir's sample app
- will discuss the next task within the Mir MVP project with @matejpavlovic until this Friday
@sergefdrv
- Finish implementing logical time in integration tests
@matejpavlovic
- Refine Y3 roadmap to be similar type as B3
- Refine Reconfiguration and Performance issues to more concrete AIs
- Execute some of above AIs
@xosmig
- Merge the availability layer prototype PR.
- Add some integration tests for the availability layer.
- Start adding complexity to the availability layer (message retransmission, persistent storage, etc.)

matejpavlovic commented 2 years ago

2022-07-25

📣 Updates

dnkolegov:
- finished integration of Mir with libp2p transport into Eudico
- added several small PRs to clean Mir and improve integration with Eudico: 1, 2, 3
- experimented with orchestration and reconfiguration: the main result is the question in the Discussion section
- reviewed several PRs
- I am still not sure about the correctness of the libp2p transport in Mir (opening connections). I asked the question on libp2p-implementers channel. Nobody has responded yet.
@sergefdrv
- Draft implementation of Reproducible integration testing with simulated time (generally ready for review, but requires rebasing)
@matejpavlovic
- OOO
@xosmig
- Basic module mocking in Mir
- Placeholders library for more advanced mocking capabilities
- Finished refactoring the testing infrastructure: PR1, PR2
- Implemented a prototype of the mempool module

🧵 Discussion

dnkolegov:
- @matejpavlovic suggested to create a new Mir node on each reconfiguration via Eudico's manager (to start with something and to have something for MVP). I experimented with this idea and found that this works not well because we have to stop the network transport and then reestablish all network connections. I was not able to make Mir nodes with libp2p transport work immediately after stopping the node, but it worked with adding Sleep command. I would suggest to improve this idea a little bit in the following way: let's add new connections into network transport and remove the old connections if necessary instead of calling net.Stop(), net.Start() and net.Connect() on each reconfiguration. So we need to add a function like NewConnections(map[NodeID]NetAddr) to the network transport interface. This function opens connections to nodes contained in the map without removing all network connection from previous stage.
  - @matejpavlovic: Yes I agree, let's re-use the existing connections. Conclusion: @dnkolegov to implement it and use it in the Eudico integration code.

🎯 Up next

dnkolegov:
- discuss with @matejpavlovic the next tasks (I may be working on Mir reconfiguration support in Eudico)
- address issue 224: I will find the latest commit where Tendermint works and push it in a separate branch on Eudico
@sergefdrv
- Rebase Reproducible integration testing with simulated time
- Contribute to Eudico’s State Manager design and implementation
@matejpavlovic
- Finalize new roadmap for Y3-M3
- Start contribute to reconfiguration-related code
@xosmig
- OOO

matejpavlovic commented 2 years ago

2022-08-01

📣 Updates

@sergefdrv
- Rebased and adjusted implementation of Reproducible integration testing with simulated time (merged)
- Made CI run integration tests with simulated time (no new tests yet)
dnkolegov:
- Modified Mir transport interface
- Minor improvements and bug fixes (1, 2)
- Refactored Eudico code to support new transport interface and reconfiguration mechanics
@matejpavlovic
- Updated Y3-M3 Roadmap. Slipping a bit, the new realistic delivery M3 delivery date including membership reconfiguration is now Aug 26th. Other features should still be done this week.
- Outline of reconfiguration implementation
- More Mir improvements
- Started working on node joining in the chat demo app
@xosmig
- Was OOO

🧵 Discussion

The outcome of most discussions is captured in the new Y3-M3 Roadmap document.
Discussions on demo day presentations in the CL Meeting Notes.

🎯 Up next

dnkolegov:
- Implement membership update submission
- Integrate the Mir availability layer into Eudico
@sergefdrv
- Implement Load generator for Mir-based orderer
@matejpavlovic
- Integrate availability layer in chat app
- If time permits, continue making chat app reconfigurable
@xosmig
- Dsl modules Demo at MoaDD

matejpavlovic commented 2 years ago

2022-08-08

📣 Updates

@dnkolegov:
- spent a lot of time trying to find the reason of this data race and why we have not seen that before
- draft implementation of the Mir reconfiguration in Eudico
- drafted itests for reconfiguration
@xosmig:
- MoaDD presentation
- A bunch of small code improvements: link1, link2, link3, link4, link5, link6, link7, link8
- Consistent Broadcast and Availability Layer demos
@matejpavlovic
- Initial (hacky) implementation of reconfiguration of the chat demo app. Currently, the newly joining node needs to get the information about the configuration out-of-band, but with that information it can join the network. For the chat demo app, this is necessary. For Eudico, the idea is to have it obtain the information from the parent network.
  🧵 Discussion
@dnkolegov: @matejpavlovic @xosmig, is the availability layer is ready? do (will) we have an example (in the chat-app) of how to use it properly?
- @xosmig: There is a separate demo for the availability layer: link. Afaik, it is not yet integrated into ISS (and, hence, to the chat-demo).
- @matejpavlovic I switched up the chat demo reconfiguration and the availability layer priorities, since the reconfiguration seemed more pressing wrt. Denis' work. I'll focus on the availability today and tomorrow, so it's integrated with ISS by tomorrow evening.
@xosmig: I am a bit concerned with the current approach to technical debt in the code. We should probably aim at writing a bit more general future-proof code. Otherwise, it is just being rewritten twice. In most cases, doing things general enough the first time is really not a problem. A few examples:
- My personal big strugle: Mir != ISS (as I am tasked to do first non-ISS protocols in Mir). Unfortunatelly, I keep seeing (unnecessarily) ISS-specific code being added regularly.
- strncov.Atoi(nodeID)
- if tr.Sim != nil {...}
- if transport, ok := tr.Modules["net"]; ok {...} (guilty, this one is mine)
- @matejpavlovic: I acknowledge this point and agree we should do better on this. To explain how we got there initially: Historically, Mir started out as an implementation of ISS and has progressively been generalized to be less and less ISS-specific. But admittedly, few parts of the code that are ISS-specific are still from the old times. Some parts were just written in an ISS-specific way because it was cognitively simpler at that time, and generalization is lagging (leaving it as debt). I agree this is sub-optimal.
  - My suggestion: Let us be stricter with this from now on and, when reviewing PRs, point out ISS-specific parts and request generalization. And ingeneral, push for only merging PRs that do not add more debt, and in rare cases where they do, it should be justified and agreed-upon.
- @xosmig: I understand why the code was written this way initially. I am more concerned about new code being added "by analogy" with the old code, thus increasing technical debt while we should aim at gradyally paying it off.
  🎯 Up next
dnkolegov:
- continue to work on Mir reconfuguration in Eudico
@matejpavlovic
- Availability
- Reconfiguration (node joining and state transfer)
@xosmig
- Hopefully finally start implementing Narwhal

matejpavlovic commented 2 years ago

2022-08-15

📣 Updates

@dnkolegov:
- I am still working on Mir reconfiguration in Eudico
  - wrote tests
  - fixed bugs in old tests
  - fixed docs
  - prepared a test/demo scenario
- PR review - 1, 2, 3
@xosmig:
- Working on Narwhal impl in Go
- Improving Mir
- Experimenting with improving DSL modules
@matejpavlovic
- Mir now supports reconfiguration. Node joining is tested with the chat app. Good candidate for the next Demo Day. Not secure yet due to partly stubby certificate verification code.
- Separate availability (mempool, content dissemination) layer integration with ISS

🧵 Discussion

Summary of sync brainstorming between @matejpavlovic and @xosmig about Mir, Narwhal, and reconfiguration:
- Narwhal implementation:
  - What persistent storage system to use? BadgerDB was used just as an example in the design document, because it happens to be used by the (inherited) WAL implementation. In principle, @matejpavlovic has no concrete preference for a particular data store. What potentially might be relevant is go-datastore.
    - Rust implementation uses RocksDB.
  - The implementation will rely on a reliable communication abstraction. As for now, the unreliable Net module can be temporarily used as a stub. @matejpavlovic to check out the updated GitHub discussion on reliable message delivery.
- Narwhal garbage collection:
  - The garbage collection in Narwhal "cuts off" some dependencies. It may become a problem when we will be adding deduplication and censorship resistence. It is not immediately clear whether it's actually necessary: maybe we could garbage-collect only ordered blocks and add "weak references" as in DagRider to make sure every block is eventually ordered? Let's look more closely at the DagRider and think more about it.
- Narwhal reconfiguration:
  - Multiple instances of Narwhal will co-exist, using a similar instantiation and garbage collection mechanism as ISS. The ordering layer (ISS in our case) already drives the advancing of epochs and configurations and the creation of checkpoints. It will simply emit analogous events to the availability module, which will instantiate and garbage-collect Narwhal instances accordingly.
  - As the ordering layer (ISS) is pulling its input from the availability layer (Narwhal), the availability certificates need not carry explicit epoch information. The ordering layer will simply pull the certificate from the corresponding instance of Narwhal.
  - The instances of Narwhal will be represented as nested modules within a main availability module.
- Mir nested modules:
  - In order to be able to kill old instances of the availability layer module and create new ones during the reconfiguration, we need something like dynamic modules. However, we don't have a clean design for dynamic modules yet. Instead, we settled on a simpler alternative, which can be implemented with a tiny modification to how Mir core processes module ids.
    - TODO(@xosmig): write down the design for submodules either in discussions or in an ADR.
    - TODO(@matejpavlovic): Introduce structured module identifiers to enable suport for nested modules

🎯 Up next

@dnkolegov:
- finish integration of Mir reconfiguration
- start working in integration of Mir's availability layer into Eudico
@xosmig:
- A simple stubby Narwhal prototype.
@matejpavlovic
- Merge reconfiguration and availability layer support
- Prepare chat reconfiguration demo

matejpavlovic commented 2 years ago

2022-08-22

📣 Updates

@dnkolegov:
- Finished adding part of Mir reconfiguration in Eudico
- Improved Mir libp2p transport
@xosmig:
- Some work on the availability layer: PR.
- Couldn't resist anymore and decided to implement code generation (in WIP branch). It turned out more difficult than I expected, but it is almost finished at this point.
@matejpavlovic
- The availability layer (multisig collector) is now also reconfigurable using "factory modules".
- Wrote lots of other code for Mir.

🧵 Discussion

@xosmig: What do we want from code generation?
- @xosmig: For example, I can generate a hierarchy of structs completely separate from the ones generated by protobufs, with Mir types (e.g., t.NodeID instead of string) and conversion functions.
  - @matejpavlovic: That would be nice to have.
    - Would that be generated from the .proto definitions?
      - @xosmig: the generator uses the protoc-generated .pb.go files as input. This choice was motivated by relative simplicity compared to working directly with .proto files since protobufs have their own type system which would need to be translated to go type system.
    - How would the generator know the difference between two different Mir types that map to the same protbuf type? E.g., if the protobuf message defines a field of type uint64, how would the generator know that it is, say, a sequence number and not an epoch number? Is it possible add additional annotations in the .proto file?
      - @xosmig: the generator looks at optional annotations on fields in .proto files, e.g.: string module = 1 [(mir.type) = "github.com/filecoin-project/mir/pkg/types.ModuleID"];
    - It would also be great to have, for each generated type, a generated constructor function that takes the fields as arguments. I would then encourage a convention of never creating an object directly through SomeObjectType{Field: val, ...} and always using the constructor. This way, should we decide to add fields to some objects, the compiler would help avoiding the default zero values for that field in instantiations of the object that one might forget to update.
      - @xosmig: yes, I already implemented the constructor functions.
- @xosmig: The baseline is that I will just generate constructors and DSL functions.
  - @matejpavlovic: Yes that's a very helpful thing. Does this also mean constructors for event protobufs?
    - I have the code to generate the constructors implemented. We need to decide to which extent we want to use it.
    - @matejpavlovic: I'd say there is no harm in generating a constructor for each event type, even if it ends up not being used.
  - @matejpavlovic: A skeleton implementation of the DSL module would also be nice, with generated handlers for each event type.
    - For this we would need to use something like service description in protobufs. This would be nice in the future, but I think goes beyond the intended scope for the first version of code generator.
    - @matejpavlovic: A coarse but simple (and I agree, not necessarily very pretty) way would be to just generate an handler for every single event type defined for the package (even for those meant as output). The user would then delete those they don't use. Although, that might require the user to edit the generated intermediate "event registration" files. I guess that could be maybe solved by another annotation, but I agree that this is way out of scope for now.
@matejpavlovic: Also in the light of the above, and as @xosmig already suggested at some point, we should clean up the protobuf definitions, as now they are quite messy. The events.proto and messages.proto are historical artifacts and a big part (if not all) of their content should be moved to files associated with the respective modules. I'll soon have a proper look at that and move things around. @xosmig if this has any impact on the code generation and you would like me to stick to some particular conventions, pls let me know.
- @xosmig: I think there is an implicit convention for event and message subtypes (e.g., isspb.Event, availabilitypb.Event, isspb.ISSMessage, mscpb.Message).
- @matejpavlovic: Yes that makes sense. (The isspb.ISSMessage should then be renamed to isspb.Message though.)
- I also don't want to support oneofs with primitive type options. Partly, because I am considering a posibility of the future where we will move to a different data model with interfaces instead of oneofs.
- Ok, note taken, that makes sense too. I won't use primitive oneofs and when refactoring, I'll remove the existing ones.

🎯 Up next

@dnkolegov:
- Implement reconfiguration by removing Mir nodes
- Integrate the Mir availability layer into Eudico
@xosmig:
- Finish the code generation
- Narwhal prototype
@matejpavlovic
- Polish reconfiguration
- Start performance measurements

matejpavlovic commented 2 years ago

2022-08-29

📣 Updates

@dnkolegov:
- Worked on Mir reconfiguration and Mir integration in Eudico:
  - data race testing
  - code cleaning
  - comments resolving
@xosmig:
- Code generation turned out to be trickier than expected, still working on it.
@matejpavlovic
- New version of Eudico’s ordering layer design document taking into account the latest developments.
- Various improvements of Mir
- Slowly, people getting interested in Mir
- Y3-M3 only waiting for related PRs to be merged
- Document for gathering further tasks for Mir / Eudico

🧵 Discussion

@xosmig: Independently defined events
Continuing: Reliable message delivery
@matejpavlovic: Please dump all you can think of in terms of further improvemts in this doc. Even very raw ideas are fine. Afterwards, we'll go through it, organize it and make a prioritized plan with actual AIs to execute.

🎯 Up next

@dnkolegov:
- Implementing and using Eudico mempool with Mir
- Using the last Mir version in Eudico
@xosmig:
- Finish the code generation.
@matejpavlovic
- Create plan for future Mir improvements
- Continue Mir implementation
- Prepare team week session on general blockchain SMR

matejpavlovic commented 2 years ago

2022-09-19

📣 Updates

@matejpavlovic
- Prioritized roadmap for next milestone
- Mir improvements:
  - SMR system abstraction
  - Several technical improvemens: 1 2 3 4 5
- Sergey switching to IPC and Rust-based projects. (Thanks @sergefdrv for your contribuons!)
- First external open-source contribution! :tada:
  - Threshold crypto
- Project proposals (for interns, new collaborators, anyone...):
@xosmig
- Was busy with research related stuff and preparing a final version for a ConsensusDay paper.
@sergefdrv
- Updated benchmarking tools to use SMR abstraction
@dnkolegov:
- worked on the Mir mempool adapted to Eudico
- tried to add semgrep linters to the Mir project but reverted, because implementation security is not top priority at present

🎯 Up next

@matejpavlovic
- Y3-M4 roadmap timing and assignment of DRIs
- Sync roadmaps with BuilderNet
- Mir preliminary perf evaluation
@sergefdrv
- Update benchmarking tools to use the new “SMR system” abstraction
@xosmig
- Finish the code generation
@dnkolegov:
- Reestablishing lost network connections
- implementing client watermark windows for limiting the number of in-flight transactions

matejpavlovic commented 2 years ago

Y3 has been merged with the B4 project, including the meeting notes.

consensus-shipyard / consensuslab