Multiple nonces #466
Multiple nonces #466
Conversation
This mirrors how Provided TXs handle topics. Now, instead of managing a global nonce stream, we can use items such as plan IDs as topics. This massively benefits re-attempts, as else we'd need a NOP TX to clear unused nonces.
|
This increases the complexity of the Tributary. This removes the potential for an honest node to publish the same intent across two distinct nonces due to syncing an alternate chain. This is a theoretical improvement to the security an honest node has when operating over multiple chains. If the malicious supermajority was ever asked to provide evidence, the same intent across multiple nonces would be valid evidence. With this, all that exists is multiple sets of data under the same intent within a nonce. This removes the ability for a malicious node to publish conflicting intents (DkgConfirmed and InvalidShare) or publish on-chain multiple instances of an intent. This saves 4 bytes per every transaction (the nonce, which is no longer broadcast). This increases the on-chain DB usage of the Tributary. A nonce must now be saved for every single intent, instead of just for every account. This is likely as bad or slightly better than storing every single TX hash on the DB (due to the key length for the nonces being ~40 bytes, and only getting a couple uses). |
|
We could also replace the nonce system with an intent system. That'd remove the de-duplication this PR offers of keys (as we'd have to save multiple copies of the intent as a key), though the DB likely optimizes that. It'd also remove the ability to require one TX be published before another. It would simplify this somewhat though. |
I don't know why this didn't trigger for me. Potentially a difference in the month of the nightly clippy?
|
This is also slightly more robust in that it allows any individual TX to take an arbitrary amount of time without stalling the global queue. |
|
The only downsides are the increased storage use and potential increase in complexity. Given the storage is ephemeral, and this removes a bit of complexity with it.... Leaning towards merge. |
Adds support for multiple nonces to Tributary's Signed transactions, just like Provided.
Enables removing NonceDecider, simplifying that out a bit. The other option would be to remove nonces entirely, yet that means two different servers could publish distinct transactions with the same effective intent. With the nonce system, we achieve effective de-duplication.
I'm not convinced this is the right move forward, yet want to run it in the CI, create a PR so it's properly indexed by GH, etc.