New RFC 38/LOGOS-CONSENSUS-GLACIER

[easye]

Problem

We need to disseminate the initial work on Logos blockchain consensus protocol in a manner that somehow introduces the "framing" that induced it, the progress that has been made, a description of the mathematical basis for consensus, the methodology of the security analysis undertaken, and what the next steps might be.

This "initial work for Logos blockchain consensus" is roughly synonymous with a description of Glacier--our novel modification of Avalanche--and motivating its innovations.

Acceptance criteria

This work shall be reviewed be suitable domain experts for completeness and accuracy. It is essential to publish something sooner rather than later to serve as the basis for discussion, and to start teasing out what the eventual overall structure of the Logos specification process will look like. As such, it is anticipated that this RFC will probably stay in a "Raw" state for quite a while.

The acceptance criteria shall include an evaluation of the actual implementation with respect to a given language.

It is a possible acceptance criteria might be to decide that such a standalone RFC on consensus is not as optimal as say splitting the RFC into a "context problem statement" with a separate implementation proposal describing Glacier. In that case we might move this RFC to "withdrawn", and decompose the work into the new units.

Details

A sizable amount of content around Logos Consensus is currently "locked up" in the private hypertext system (notion.so) where it was created. The problem is not just a matter of making this information public, but collation/editing of various parts as an initial coherent whole that can be used as the basis for further specification/discussion. Using the notion.so content as a basis, we will produce a terse, targeted "RFC" that is accessible and useful to potential and actual Logos contributors.

Possible Solutions

Write such an RFC as a series of pull requests.

Notes

Important to get a daily cadence of progress available for others to review.

[easye]

initial coherent whole

It is not the case that the notion content is not coherent: it is very coherent. It is more that we need to consider an audience and goals in a standalone document such as an RFC.

[easye]

Currently I favor utilizing some of Alexander's work on the mathematical exposition of Glacier, as with it is perhaps easier to see that Glacier is indeed one of many members of "Snow": a family of algorithms with different tradeoffs.

[corpetty]

The underlying consensus algorithm is quite simple to implement. The acceptance criteria should mainly be that someone can implement it in a given language completely such that it yields the same results.

[easye]

The underlying consensus algorithm is quite simple to implement. The acceptance criteria should mainly be that someone can implement it in a given language completely such that it yields the same results.

Alright. I have a slight problem conceptualizing the evaluation the ease/fidelity of implementations that have yet to occur, but I will somehow figure out how to cover this. Test suites might be one idea.

[oskarth]

The underlying consensus algorithm is quite simple to implement. The acceptance criteria should mainly be that someone can implement it in a given language completely such that it yields the same results.

Agree.

While test suites would be nice, and definitely vital at a later state for consensus, I don't think it should block the initial protocol description. Waku v2 doesn't have official integration test vectors or so yet (though unofficial ones), and we've got 3.5 implementations now

[corpetty]

implementations that have yet to occur

We have it in Rust, it might be worthwhile to talk with Daniel (Logos engineer) about how he did it.

[easye]

We have it in Rust, it might be worthwhile to talk with Daniel (Logos engineer) about how he did it.

I have reviewed the code somewhat and will talk to Daniel as I have questions.

[jimstir]

Closing as discussion seems to be complete.