Quai Network Community AMA

So you said there's an active devnet running. When did that go up and how confident are you in that being like a stable implementation of home? It's certainly the best network we've ever put up today. We're about 48 hours in. And we run at, when we do testing, we run at about 10 next speed. So two days is worth about 20 of what you would consider like a test net. So the cool part is we did come up with like some bugs today related to different processes in the node. But the interesting part is we never had to delete the database or restart the blockchain. So throughout the day, none of the issues were effectively consensus. Everything was post-consensus. So it's pretty cool to be at the point where you're not deleting databases because it tells you how close you are to getting this to work. And so now that we've got that stable blockchain, you could say, Alan, I'd love to hear from you. I know you're really going hard on the side of testing and integration testing with all the different toolings we're going to be offering for the test net. Can you explain what the testing process is like internally right now? What things are being tested and what's the goal of all this testing? I think you're muted. You able to hear me? Oh, yeah. My bad. Totally was. But yeah, thank you for having me on today, Max. The kind of system and the process of what we're trying to do with testing is to emulate that user experience when we launch test net. So we want to really iron out all of the kinks and problems that could exist down the line and get ahead of it. So we've talked a bit about that process for a pretty long time, but it's all the basic tools. So when you use a test net, what's your kind of starter kit? You have a wallet. You have some sort of faucet that you receive the test net coins to. So say I've spin up a new wallet, and then I go hit a faucet and get 0.15 to send around to my friends. And then in order to track all of those, you would then also need a block explorer. And other sort of mechanisms to do contract deployments. So we have that starter ecosystem that we're developing on and running alongside DevNet. And we have a long list. So we're trying to be as thorough and as predictable as possible. And then through that system as well, we can have all the proper documentation and systems available for other people to expand and build upon what we've done so far. So when you're going through this integration testing process, is it all this tooling needs to be perfect production ready? Or are you just trying to make sure that there's no kind of glaring issues for the test net and that people are able to use the network? Yeah, I mean, it makes a both, right? So this next test net's going to have a lot of eyes on it. So we do want it to be as close to production, slash, main net, like as possible. So we would definitely want to see very minor changes in regards to infrastructure from now to September. And then there will still will be problems that will arise. So nothing's going to be perfect whenever we get from 10 users now in DevNet to 10,000 users on test net launch. And obviously demand will be unpredictable. It'll kind of add in flow. So at some points, it'll be 10,000 active users. And at some points, it'll be 1,000 active users. So we want to be able to handle all of that different type of interaction and then be able to also grow that current ecosystem that we have now. So bringing in other tools, letting other people build tools, being able to handle demand across the systems and contracts that people build during the test net. And the more that we have prepared now, the more we'll be able to spend our time as a team facilitating that. And I'm sure we'll get into that a little bit later with quite Genesis and a few of the other ecosystem things we're doing. Absolutely. I've got a bunch more questions on tooling and ecosystem and all that good stuff. But before we jump too deep into that, I wanted to talk to you a bit more, Dr. K, about poem and the implementation of poem. So for those of you that are maybe a bit unfamiliar, poem stands for proof of entropy minima. And it is a new method of reaching consensus, or a consensus mechanism, kind of comparable to proof of work or proof of state. So this is kind of a fundamental shift in the way that Kwai will be working. But I'll kind of leave the rest to you, Dr. K. Can you give kind of a high level explanation of what poem is and maybe how it differs from something like proof of work? Sure. So yeah, let me see if I can summarize this. I don't know if I've gotten this quite perfect. But I guess we'll give another shot at it. It'll a very new topic for everyone who's in here. The paper just came out this month. So yeah. And honestly, we're still kind of understanding the implications of poem itself. But basically, the summary is all proof of work, blockchains, have misunderstood what they're trying to measure. They haven't represented it or measured it in a physically meaningful way. But what they're really trying to do is they're trying to coordinate the sequencing of events from disparate nodes using a measurement. But the thing that they're actually doing is reducing entropy. They're just not measuring it correctly. And then they're not making their choices correctly. So basically, what we realized is that if you're doing a hash-based work function as a mechanism of decision, what we're doing is we're reducing entropy within the system or put another way we're minimizing divergence. And if we measure the any given block by the amount of entropy reduced, our divergence reduced, we will always have unique choices and we will always have preference for a block. So what that means is if I have many chains with many nodes producing many blocks, the second bit they produce the block, given the a priori defined rules of the blockchain, everybody will already make the exact same choice on choosing that block or not, independent of actually having seen the block yet. So what that means is we've created what we would call a time invariant sequence. And in doing that, we make it so that we can coordinate an infinite number of threads or block chains. And we could do it without creating the need for time-based aging between state transitions. And so you made a very interesting comment to me today when we were talking about this. And you mentioned that this completely almost redefines what consensus is in block chains. You mentioned specifically that that Kui with poem will now always be at consensus. Can you kind of elaborate on that? Yeah, so the interesting thing is because every block that's generated, if you generate a block, when you generate that block, it has a certain amount of entropy reduction. And I can measure that perfectly. So that block will not have any other block has the same amount of entropy reduction. Therefore, I will never have undecided preference. If I look at Bitcoin and I look at two blocks that are built on a common parent, so a fork, those blocks are co-washed to the difficulty threshold. So from the network standpoint, they have equal preference to both blocks. And the only thing that determines which block is chosen is by how fast they had propagated in the network. So when they were received a time-based quantity, and then the next block built on top of that, a stochastic phenomena. So every time a fork is generated in Bitcoin, it can take 10 minutes to resolve the fork. But in poem, every single block has separated preference. So if you generate a block, it will have a value, and that value even is determined by the block itself. So even though I haven't seen that block yet, I will always value it the exact same amount that you value it. So we've technically instantaneously reached consensus on how to treat that block, even though I haven't yet seen the block. So in some ways, this is consensus-less. Or a consensus is the code itself that's deployed at the Genesis block. It doesn't evolve as a property of the blocks being produced. Interesting. So when we're talking about the impacts of this, it seems like it's really addressing a massive overlook in inefficiency in proof of work. Do you have any idea or concept of how significant the addressing of this inefficiency will be? What are the impacts of this going to be on the network itself? Is it going to manifest in higher TPS or speed or what kind of stuff will actually be in the network? So quantitatively, the difference here is on the order of a million. Not like I'm just throwing a number out there. This is six orders of magnitude better. There's obviously assumptions in making that. But if I said Bitcoin with proof work, like Bitcoin with Poem, Poem is mathematically like a million times more efficient, roughly speaking. In terms of what it means for the user and for the chain, it means that we can effectively coordinate an infinite number of threads because we have no time to consensus. Consensus is deterministic and everybody is always in consensus, so to speak. So Poem really kind of opens the door for the multi-chain future that everyone's kind of talking about. Yeah, so I mean, when we say multi-chain here, what we're saying though is multi-chains in Chy. Right? The multi-chain future when I talk about like Ethereum and you know, finance and I'm talking about bridging between the two of them, that dies on its face. And in some ways, Poem can provide the proof that that can never work. We already see it heuristically because if we look at the time to cross in one of these decentralized bridges between finance and Ethereum, it's only order seven to 14 days. Right? And that time is because those are uncordinated systems that are inefficiently reaching consensus. But if I use something like Poem with a closely coupled system, I have no uncertainty in either system at all any of the time. You know, I don't necessarily know what will get finalized, but because I always know how a choice will be made, given a certain set of data, there's actually no weight required once the data arrives. So I don't have to like get data and then wait and then hope that that statistically like becomes the thing before I do the next thing. I just have the data. I'm time invariant. I move on to the next step. Yeah, I'm gonna, I'll chime in here a little bit more just kind of in regards to the origin story of Poem for the listeners that aren't as familiar and kind of where we're headed and how we got to this point. Generally, you know, if you're not familiar with Quine Network, obviously go read the docs.quite.network. The system in regards to the hierarchy relies on the merged mind sort of levels of execution and what we were seeing in consensus before we had a system like Poem is that when you get an uncle block or an orphan at a higher level, so say at a prime or region level, it would take time to resolve that. And you would get, we had to kind of back ourselves into these corners whenever we looked at our system design and we said, okay, we have an uncle in our top level and now the subordinates of the lower level sort of have to mine against each other to figure out how to resolve that conflict top down. So there's a conflict in the higher level, the lower levels have to resolve that conflict and it takes time and waste hash or also can sort of create these network dispersions that are not favorable or not ideal. And ultimately, that's a result of the hierarchical long-est chain rule and also sort of other topologies in how we structured the hierarchy and how we started to work the line. Hold on, no. It's a result of inefficiently measuring a property. Right, so the thing is, we didn't realize what we were measuring, right, work in the concept of a proof of work blockchain is meaningless. And the way that they're measuring it is meaningless. And it's not even like a close approximation, they're off. They're using something that's geometric