Develop a new blockchain for managing FROST signing sessions #163
Labels
Comments
kayabaNerve
added
feature
Closed
|
Required transactions:
|
kayabaNerve
added a commit
that referenced
this issue
Dec 8, 2022
Closes #40. I *could* have added a serialization trait to Algorithm and written a ton of data to disk, while requiring Algorithm implementors also accept such work. Instead, I moved preprocess to a seeded RNG (Chacha20) which should be as secure as the regular RNG. Rebuilding from cache simply loads the previously used Chacha seed, making the Algorithm oblivious to the fact it's being rebuilt from a cache. This removes any requirements for it to be modified while guaranteeing equivalency. This builds on the last commit which delayed determining the signing set till post-preprocess acquisition. Unfortunately, that commit did force preprocess from ThresholdView to ThresholdKeys which had visible effects on Monero. Serai will actually need delayed set determination for #163, and overall, it remains better, hence it's inclusion.
kayabaNerve
added a commit
that referenced
this issue
Dec 9, 2022
* Remove the explicit included participants from FROST Now, whoever submits preprocesses becomes the signing set. Better separates preprocess from sign, at the cost of slightly more annoying integrations (Monero needs to now independently lagrange/offset its key images). * Support caching preprocesses Closes #40. I *could* have added a serialization trait to Algorithm and written a ton of data to disk, while requiring Algorithm implementors also accept such work. Instead, I moved preprocess to a seeded RNG (Chacha20) which should be as secure as the regular RNG. Rebuilding from cache simply loads the previously used Chacha seed, making the Algorithm oblivious to the fact it's being rebuilt from a cache. This removes any requirements for it to be modified while guaranteeing equivalency. This builds on the last commit which delayed determining the signing set till post-preprocess acquisition. Unfortunately, that commit did force preprocess from ThresholdView to ThresholdKeys which had visible effects on Monero. Serai will actually need delayed set determination for #163, and overall, it remains better, hence it's inclusion. * Document FROST preprocess caching * Update ethereum to new FROST * Fix bug in Monero offset calculation and update processor
Closed
This was referenced Mar 20, 2023
kayabaNerve
added a commit
that referenced
this issue
Mar 26, 2023
The original intent was to use inherent transactions to prevent needing to vote on-chain, which would spam the chain with worthless votes. Inherent transactions, and our Tendermint library, would use the BFT's processs voting to also vote on all included transactions. This perfectly collapses integrity voting creating *no additional on-chain costs*. Unfortunately, this led to issues such as #6, along with questions of validator scalability when all validators are expencted to participate in consensus (in order to vote on if the included instructions are valid). This has been summarized in #241. With this change, we can remove Tendermint from Substrate. This greatly decreases our complexity. While I'm unhappy with the amount of time spent on it, just to reach this conclusion, thankfully tendermint-machine itself is still usable for #163. This also has reached a tipping point recently as the polkadot-v0.9.40 branch of substrate changed how syncing works, requiring further changes to sc-tendermint. These have no value if we're just going to get rid of it later, due to fundamental design issues, yet I would like to keep Substrate updated. This should be followed by moving back to GRANDPA, enabling closing most open Tendermint issues. Please note the current in-instructions-pallet does not actually verify the included signature yet. It's marked TODO, despite this bing critical.
kayabaNerve
added a commit
that referenced
this issue
Mar 26, 2023
Updates to polkadot-v0.9.40, with a variety of dependency updates accordingly. Substrate thankfully now uses k256 0.13, pathing the way for #256. We couldn't upgrade to polkadot-v0.9.40 without this due to polkadot-v0.9.40 having fundamental changes to syncing. While we could've updated tendermint, it's not worth the continued development effort given its inability to work with multiple validator sets. Purges sc-tendermint. Keeps tendermint-machine for #163. Closes #137, #148, #157, #171. #96 and #99 should be re-scoped/clarified. #134 and #159 also should be clarified. #169 is also no longer a priority since we're only considering temporal deployments of tendermint. #170 also isn't since we're looking at effectively sharded validator sets, so there should be no singular large set needing high performance.
This was referenced Mar 26, 2023
|
This is being called tributary. |
|
Tributary, as a blockchain framework, was largely finished in f48022c. The Serai-specific transaction can be found here: https://github.com/serai-dex/serai/blob/d5a12a9b977a802413708b6f47bb389e80b9786f/coordinator/src/transaction.rs And the processor lost its independence on this here: e2571a4 Now it's just about writing the coordinator as a whole. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thanks to
tendermint-machine, we have a crate offering BFT consensus over abstract blockchains. We can define a new blockchain, which is incredibly minimal, to collect preprocesses. Then, the signing set is simply defined as whoever publishes preprocesses first. The BFT process ensures ordering, message delivery, creates a shared message log, enables identifying offline/malicious parties...In practice for Serai, we'd create a new instance for each validator set. This would live in the processor.
This is one of two ways Serai can create a robust signing process not simply based on random chance. See #162.
Credit to hdevalence for the idea.
The text was updated successfully, but these errors were encountered: