marijanp
commented
9 months ago Hey Andrzej, thank you for the feedback.
While the current prototype dives into details and showcases some advanced thinking, I would like to ensure our foundation is rock-solid before we delve into such specific functionalities
The structure of the document is starting at a very high level, describing what the end product should be capable of doing. Reading further we enumerate the requirements, which are more specific, test-cases, etc. and from that we derive a higher-level architecture I.e. we take the bottom-down approach. I don't see where the advanced thinking is happening, please elaborate.
- Define ZK Circuit: A succinct description of the logic and assertions to be implemented in the ZK circuit, to ensure we understand the basics.
- Detail L1 Contract: A thorough breakdown of the L1 contract, including necessary stored data (maybe just the merkle root of account balances?) and the mechanics of the verify endpoint.
To me this sounds like starting with the details. We cannot start digging deep into these things if we do not specify on a very high-level what we are actually going to build and what the boundaries of that product are.
But I agree that each of us should dig deeper into the technologies that we will need to use because we derived that from the requirements e.g. it's clear that we will build the product on top of the Casper chain and of course we need to know what the limitations/ possibilities are. Moreover we should have a good idea on how we are going to proove the transactions. We should also get a good overview over the differences between different prooving systems, as it is fairly clear that we will need to use one. This was already done by most of the team-members at this point. And we are all still consulting the documentations while writing the spec.
An RFC appraoch is too slow and too scattered for this first phase. We need to define and agree on what the minimal system should do, derive the components and how they are going to interact with each other. From that we can iteratively build up the system, and come up with improvements.
Hey Team!
A massive shout-out to @marijanp for initiating the Kairos specification!
While the current prototype dives into details and showcases some advanced thinking, I would like to ensure our foundation is rock-solid before we delve into such specific functionalities. Especially as we navigate the complexities of building an L2 solution with ZK-rollups, it's imperative to focus on establishing a clean and effective core.
Here’s a slightly pivoted proposal for our initial focus:
verifyendpoint.Choosing architectures, deciding on data availability, and establishing API, etc., while crucial, might be a tad premature at this point. Building upon a robust foundation that everyone is on board with will pave the way for smoother advancements in the future.
How about adopting an RFC-like model for our workflow? Introducing something like a KEP (Kairos Enhancement Proposal) could offer a structured way for us to gradually define and integrate missing components, like handling deposits, in a transparent and inclusive manner.
Building progressively, block by block, is crucial to avoid pitfalls and ensure future adaptability. Drawing insights from established projects like Polygon CDK could provide valuable perspectives and potentially, a few shortcuts!
Your thoughts?