Cardinal-Cryptography / AlephBFT

Rust implementation of Aleph consensus protocol
https://cardinal-cryptography.github.io/AlephBFT/index.html
Apache License 2.0
56 stars 28 forks source link

return the creator of a unit with the unit data when the unit is finalized #330

Closed joschisan closed 1 year ago

joschisan commented 1 year ago

This pr is supposed to simplify the integration of Aleph Bft into Fedimint, a byzantine fault tolerant decentralised chaumian ecash mint we call a Federation. Fedimint uses Aleph to order incoming transactions submitted by the clients. The inputs and outputs of the transaction are either chaumian ecash notes, on-chain bitcoin or smart contracts that enable integration with the bitcoin lightning network enabling instant settlement. After a transaction has been ordered by Aleph the system has to achieve consensus wether a transaction is valid by validating all inputs and outputs individually.

An on-chain bitcoin input is the output of a bitcoin transaction that sends money to the Federation and is at least six blocks deep in the blockchain. Therefore we need to achieve consensus on the current block height of the bitcoin blockchain to validate the on-chain bitcoin input.

An on-chain bitcoin output is a bitcoin transaction that the federation threshold signs that sends money from the Federation to the clients requested bitcoin address. To assure that the bitcoin transaction will be included into the bitcoin blockchain the Federation has to add a high enough fee to the transaction which is also paid by the user. Therefore, to validate an on-chain output of a Fedimint transaction the Federation has to achieve consensus on the current ferrate necessary.

Finally, Lightning outputs of a Fedimint transaction are so called Hash Timelocked Contracts or HTLCs. To check wether a time lock has passed the system has to achieve consensus on the current time.

To achieve consensus on an integer like block height or ferrate to submit additional types of consensus items to the broadcast alongside the transactions from the clients. In our examples a node would submit its local ferrate and block height to the broadcast which we call votes. We remember the last such vote for every node and then recalculate the median to achieve consensus every time a vote is updated. Therefore we need to know which node submitted a vote. The naive solution would be to sign every vote we want to submit with the keychain before submitting it to aleph bft. While this is not an issue with strictly increasing values such as block height in case of the ferrate however there could be attacks by resubmitting an old vote by a different node; this is generally known as replay attacks. Hence we would have to sign an increasing integer for every submitted vote and save the integer corresponding to the last vote to prevent such attacks. This introduces unnecessary complexity as the extra information that needs to be returned is trivially available.

Furthermore, Fedimint is built as an extensible system that can be extended with additional functionality by third parties in the form of new input and output types as well as new consensus items that are needed to validate these inputs and outputs. One extension currently in development is called stability pools which allows clients to enter smart contracts with financial service providers to hedge against falling dollar prices of bitcoin. To enforce those contracts the federation needs to achieve consensus on the current dollar value of bitcoin.

github-actions[bot] commented 1 year ago

Please make sure the following happened

timorleph commented 1 year ago

There are some lints left, see unsuccessful checks.