Discussion topic for RFC 49 – PARSEC
See the dev branch of the routing repository for a Rust definition of the following concepts:
enum State; struct NodeState; struct PublicInfo; struct Proof; struct Vote<T>; struct Block<T>;
I couldn’t find these structs in the repo. Am I missing something?
Ah thanks, I see my mistake was that search on github only looks in the master branch.
I shoulda used grep on my local copy of the repo
I have seen with great pleasure your announcement and read your whitepaper about PARSEC. I have been comparing a lot of consensus system over the last few months and I am glad that you come to basically the same conclusions about what the “optimal solution” might look like. I would gladly dive deeper into your algorithm, do you by any chance need some help in fleshing out details?
Can you please provide a little more background to your knowledge in this area. You are more likely to get a response if you do.
Hey rob, sure. I studied physics with a focus on theoretical particle physics and have been working on two crypto-projects for about 2 years, where we are working on a decentralized infrastructure for apps. See https://libertaria.world/de/ and https://iop.global/. The two projects are cooperating and trying to be complimentary. One of them is running an ERC20 token, while the other one is running it’s own bitcoin forked blockchain where we are trying out a POW system modified with community voting. I am responsible for most of that codebase. Both of them will switch over to their “own” consensus system hopefully this year. Both of them will most likely be coded in Rust. While one of them is going to base it’s consensus more on the AlgoRAND approach, the other will most follow in the footsteps of Swirlds and your work. While I am – let’s say “adequate” – in C/C++ and Python, doing some Rust, and doing the backend programming for one of the blockchains, I am more one of the guys reading papers, writing formulas and running simulations otherwise.
We have released the paper and RFC for peer review. The video is being uploaded now. So that should be a lot of info. We are always keen to make sure the documentation is a concrete as possible. For instance, we have a weak sync assumption in our concrete coin component and this is the only thing anyone has thought was not as rigorous as it should be (thinking all assumptions must be proven ?). That’s somewhat helpful but is really another stage to the core algorithm though (i.e. hashgraph etc. do not even show how to use a common coin, never mind concrete). So making that more clear would be good and then peer review of the paper/rfc will also be helpful.
Thanks for the offer, shout if you need any pointers.