You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After the core Team meeting on the 24th of March and to align with the updated Sharding Spec , the Proposer Client Implementation will be as following :
In Phase 1 for our implementation there will be no state execution and no P2P wire protocol will be implemented and everything will be implemented using the local file system. Also the collations will basically consists of blobs of random data rather than actual transactions. Updated goals to be accomplished for the proposer client:
Create a basic interface for the Proposer , where it is basically be able to interact with the main shard over JSON-RPC
The proposer client should be able use the local filesystem to process arbitrary data blobs into collation bodies and collation headers
Then propose the collation header to the collator to be added to the shard chain.
The text was updated successfully, but these errors were encountered:
Hey @nisdas@prestonvanloon @terenc3t, as we just discussed over chat, we need to figure out the major functionality behind a proposer node and how we can split its parts up into multiple tasks distributed across the team.
My proposal is that we will need the following PR's:
Subscribe to pending tx's from the geth node and filter out the ones that ask for too much gas
Process pending tx's to create a collation object, along with a collation header and body
Create a cryptographically signed deposit with a proof that is included in the collation header that signifies the payout a collator will receive
Create the actual proposals pool (will require some p2p networking we'll need to figure out)
Broadcast collation headers into the proposals pool (we withhold the body until a validator accepts)
Create the ability to receive double-signed collation headers (once a collator accepts a collation header, signs it, and sends it back) so that the proposer can then send the collator the rest of the collation body
Let me know if I missed anything and we can start a discussion on this through here.
After the core Team meeting on the 24th of March and to align with the updated Sharding Spec , the Proposer Client Implementation will be as following :
In Phase 1 for our implementation there will be no state execution and no P2P wire protocol will be implemented and everything will be implemented using the local file system. Also the collations will basically consists of blobs of random data rather than actual transactions. Updated goals to be accomplished for the proposer client:
The text was updated successfully, but these errors were encountered: