Time | Item | Who | Notes |
---|
| What Consensus needs | Michael Birch (Unlicensed) | - Describes the message types needed by Consensus
- Discuss what happens when new code is added to the blockchain
|
| Frame what consensus needs | Nash Foster | - Node should have an API that accepts input.
- Node informs that some input was received, signed by a key
- What kinds of transactions can the consensus mechanism can support
- Consensus mechanism needs to share this between nodes.
- COMM events have some structure, this is what the algorithm cares about.
|
|
|
| - Message type → New block. Parent block or parent blocks, Post state that results from the computations that were done, and the reason for these computations, justification block /slots.
- basically a bunch of hashes of past blocks.
|
|
|
| - Can the consensus team create the protos and GRPC API to create and send the messages they need in order to get started?
- They will write up a protobuf schema and hand to Pawel, they can start sending messages?
- Need an API to send the messages.
- How do they decide which peers to send messages to. Different types of peers, validating peers and non-validating peers
- They will get an interface that will help them to communicate on the network.
|
| Rollback |
| - Kent asks about rollback?
|
| GRPC Protobuf in comms? | Pawel Szulc (Unlicensed) | - Are we using protos to communicate between Peers?
|
| Where does casper live? |
| - Casper will be a client of the tuplespace
- Casper will be written in Scala
- Bonding and unbonding portions are in Rholang
- Slashing portion is in Rholang
|
| Dive into Communications | Nash Foster/ Pawel Szulc (Unlicensed) | - Current Comms uses UDP Handrolled thing.
|