I agree that programmability and composability of the consensus token are challenging issues, and that the core has to balance between efficiency and flexibility. I am curious about how your project handles invalid transactions and heavy computations. How do you ensure the security and correctness of the consensus protocol?
Transactions of the consensus token are simple and fully validated, anything else that pays a fee is accepted. Then meaningless data is ignored, as it was not rejected.
I understand that scalability is an important goal for any distributed system, but I wonder how you deal with the hurdle for composability. Do you have any examples of applications that can benefit from your approach? How do you compare your project with other existing solutions in the field?
An original idea was to deploy EMV (or equivalent) for apps that need composability.
Not so long ago, I accidentally spotted ZEXE. It can be seen as a ZeroCash-style approach to composability of heavy computations. As intriguing as unhandy, it lacks concurrency. You can see similar issue on Cardano.
Got high on this ZK stuff, but worry about performance. Seemingly, Mina is able to cover the whole blockchain with a single zk-SNARK...
I look forward to hearing more from you and learning about your project. Thank you for your valuable contribution to the discussion. 😊
So far, the essential difference between Blacknet and Celestia is data availability, but I'd expect more divergence in the future.
This technology will allow companies to create blockchain networks with different consensus mechanisms, privacy features, and smart contracts
Consensus on top of consensus sounds redundant, otherwise it could be anything:
total recall