Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation on how to use the subtrate compatible finality-aleph consensus #1726

Open
hhamud opened this issue May 15, 2024 · 5 comments
Open

Comments

@hhamud
Copy link

hhamud commented May 15, 2024

I have read your original alephBFT API documentation but I noticed that you also have a subtrate compatible version here. I wanted to know how to integrate that component instead into a subtrate compatible node.

If this is the wrong place to ask such a question then I will delete and ask somewhere else.

Thanks in advance.

@ggawryal
Copy link
Contributor

ggawryal commented May 21, 2024

Hi @hhamud,

The code in AlephBFT repo is a standalone consensus implementation for general purposes, and here we have only its integration with substrate. This integration is done in https://github.com/Cardinal-Cryptography/aleph-node/tree/r-13.3/finality-aleph.

However, our priority was always adding new features to Aleph Zero blockchain, which may make it harder to reuse our substrate integration of our consensus for other blockchains.
That being said, not everything used in finality-aleph is absolutely necessary to run a custom blockchain, as well as we might rely too much in some parts of the code on some specific substrate client parts (like Aura).

Nevertheless, the integration includes, inter alia:

  • Implementing data availability for AlephBFT,
  • Handling session switches and possible AlephBFT version upgrades,
  • Implementing own block sync protocol, more tailored to AlephBFT (currently we're finishing this) - we found that the one implemented in substrate is not really consensus agnostic, as it assumes that the consensus mechanism is somewhat based on the longest chain rule, and AlephBFT inherently is not. This caused us some problems in the past.

You can also see how the blockchain's components, and particularly finality-aleph is initialized there: https://github.com/Cardinal-Cryptography/aleph-node/blob/r-13.3/bin/node/src/service.rs.

@hhamud
Copy link
Author

hhamud commented May 21, 2024

Thanks for the reply. I am fine with it depending on aura for block authorship, in my case I'm mainly concerned with block finalisation.

Could you point to where the code is for the block sync issues?

@ggawryal
Copy link
Contributor

New sync protocol is there: https://github.com/Cardinal-Cryptography/aleph-node/tree/main/finality-aleph/src/sync.

And you can see how it's initialized there:

let sync_io = SyncIO::new(

@hhamud
Copy link
Author

hhamud commented Jun 1, 2024

You are using a forked version of the polkadot-sdk. What version is it forked from and what changes were made to it that were necessary?

@Marcin-Radecki
Copy link
Contributor

Hi, aleph-node 13.3 version is based on polkadot-sdk 1.2.0. You can see all the changes to upstream branch here: paritytech/polkadot-sdk@polkadot-v1.2.0...Cardinal-Cryptography:polkadot-sdk:aleph-v1.2.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants