Multiplying Developer Impact and Speed for Global Adoption | Riley Stephens - Quai Network
Ethereum Denver·Thu, Oct 9, 2025, 12:00 AM
How to build a next-gen toolset for the original ETH 2.0 roadmap to maximize the impact of developers. By abstracting multi-chain, sharded systems with novel consensus mechanisms we can achieve mass adoption and have a global impact. 🚀 Get Ready for ETHDenver 2025! 🚀 We're already hard at work preparing for next year's biggest Web3 event! Keep your eyes peeled for more info on ETHDenver 2025—it’s going to be epic! 🌟
Transcript
[Music] hello ladies gentlemen bidders of all ages my name is Riley I am the director of Integrations engineering for qu Network and today I'll be talking to you about how to multiply developer impact and speed for Global adoption and so really what that boils down to it's a lot of fancy words to say as developers we can do more in less time with better tools so I'm going to talk to you a little bit today about how we at qu Network have kind of approached our building to tools and how we hope the industry as a whole moves towards building tools for their users so first let me talk a little bit about quad Network to help you understand what it is that we are trying to build for when we design our tool set so first qu network is a scalable programmable proof of work blockchain Network okay we are a monolithic Network meaning that there are not l2s built on top of us but instead we actually incorporate horizontal sharding into a hierarchy of merged minded blockchains in order to do our scaling okay and so what this means from a technical perspective is that we have a sharded address and execution space that we are taking into account when building on quad Network okay so that actually ends up being a pretty good bit of complexity for the user from an outside perspective okay in addition to that architecture Quai Network actually is a two token system we have qu which is a gas token which kind of applies to the saving model meaning it is intended to be deflationary over time and Quai operates within the qu Ledger okay this is an evm or account-based Ledger our second token which we call colloquially the energy dollar is called Chi okay Chi actually operates in a totally separate Ledger from Quai they still maintain or they're collocated within shards you can say so for every Shard we do have both a quii ledger and aqi Ledger okay but Chi is is a utxo based Ledger it is not an account based Ledger similar to Quai this does kind of make it a bit of a fragmented experiment experience from the outside so this actually means our tooling has a lot of work to do to unify this experience for developers okay so we kind of have this philosophy that we abide by and I think this is generally applicable to other blockchain networks but even Beyond blockchain Network systems in general okay and this and the philosophy is the greater the complexity of the system the better the tools must be okay and so if we can put it into an example if we have system a and system B system a has a very high level of complexity system B has let's say an average level of complexity in order for a developer to do the same amount in the same time on system a and system B the tool set for system a must be better okay this is a very simple principle but it actually does matter quite a bit when considering the complexity of your system and how you're going to approach the building its tools so let me talk a little bit about how we actually philosophize these these design principles okay we kind of want to take a first principles approach to building our tools and so our main philosophy is for a any user we want to reduce their cognitive load or their cognitive burden associated with operating within our Network okay so really as a as a developer whenever I try to build something or interact with any system I have an intention of what it is that I want to do anything ancillary to that intention is cognitive load okay if I have to consider something that is not helping me execute upon my intention that is additional overhead that I should not really have to consider so let's talk about how we actually tackle this problem in Quan Network so like I mentioned a few slides ago we are a hierarchy of merged Mind Block blockchains with a sharded address and execution space with two ledgers per Shard evm utxo as a developer if I just want to send an evm transaction if I just want to send Qui from me to someone else that's a lot of additional things to consider that is outside of my intention my intention being that I just want to send Qui okay so what we do is we actually say let's just let them focus on the intention let's make sure that our tool set handles the complexity of this multi- sharded environment handles the complexity of deriving addresses that are valid in Shard handle the complexity of routing requests to the proper shard in the first place okay the complexity actually grows when you think that as a node or a miner I don't have to actually provide data or mine for the entire network I can take a slice okay we call them slice nodes and a slice node is starting at the High level chain which we call Prime we can actually go back just a few slides for to help Envision this okay so there are three levels in the hierarchy are prime region and Zone zones are we could think of as any L2 or an L1 this is the chain that I as a user am interacting with if I want to Sendai I will direct my transaction to one of these zones the higher level chains are actually to orchestrate State transfer across the zones okay so let's think about this in a an actual concrete example so if I am in zone one and I want to send a transaction from zone two or two Zone 2 let's imagine these two zones are collocated in the same region okay if I want to make a transaction from Zone one to zone two the region chain for that region will help orchestrate that state transfer if I want to send a transaction from let's say Zone one to zone five zone five might be in a different region well in this case we're actually going to use the prime chain to orchestrate that transfer okay that state transition there so there's quite a bit going on here but me as a user I only care about sending on Zone one to zone two I don't care about any of the state transfer I don't care about this hierarchy I just want to do my intent okay so let's go right back here so that goes back to this cognitive load don't think about prime don't think about region don't think about any of this sort of trustless bridging all you have to do is provide an address that's valid in zone two which which someone will supply for you and just the value and the tooling handles the rest okay so our Tooling in this case is called ques or the quis JavaScript SDK that is what that is our primary dedicated tool set that I'm I'm going to be referencing here quite a bit so our next philosophy is actually reduce the number of steps to complete a task let's just go back to the same example I the user just want to send funds it might even be within the same Zone just another user in the same Zone as me I just want to send them Qui well let's think about the steps required to do that okay first I need to supply the the two address the value I want to send I need to estimate gas I need to go to get a gas price I need to know how many transactions that I've sent so I can set my knots I need to make sure I set my chain ID right and this is you know just just in this sort of very basic transaction you you kind of get up to you know almost double digit steps and this is the most basic form of transaction there is okay so what does it mean to reduce steps and let's go back to what I was talking about with developer intent if I'm a developer and my intent is to send value I just want to provide my value to send and who I want to send it to the rest should be done for me I don't care about estimating gas for the most part let's say on average the average user doesn't want to set these things it should be set for me under the hood and then if we start talking about Chi the complexities can continue to grow okay so with Chi not only is it a utxo based Ledger similar to how Bitcoin operates but it is strictly denominated very similar to how you might think about actual physical cash okay and that's how we designed Chi was to be electronic cash we want you to spend cheap okay and so the reason we do this is is both for for privacy and to make sure that you cannot differentiate between denominations okay so like a 5G denomination is a 5G denomination it is not scriptable it is not non-fungible in any way shape or form it is strictly to be transferred however you run into a problem when you're trying to spend several of these denominations not a problem necessarily but an an extra set of complexity okay let's imagine you're at the store you want to pay for something that costs $13 okay you might have a $20 bill that'll cover it you might have five or three fives and those three fives would also cover it but the change you get back will differ and an additional set of complexity within Chi is that it actually enforces address non reuse per Transaction what does that mean well address non reuse means that for every output within a transaction there must be a unique address okay so the way utx shows work we're not going to go into a whole Workshop here but just for any curiosity you have transaction inputs you have trans transaction outputs and in the Bitcoin world you might only have one output that goes to the recipient you want to send these outputs can be of arbitrary value it can be 025 Bitcoin it can be 1 million Bitcoin does not care okay but you can imagine if we go back to that example I just gave you where you're at a grocery store and you're spending these these inputs if I have three fives they go out as three inputs and then I need to get $2 back in this case chi I need to get two one Chi denominations back in the outputs okay you can imagine this change making problem begins to balloon after a long period of time users have to manage all these addresses users have to care about how many addresses you give them in order for them to properly map it to the output okay so we're going to get into that how we solve that in just a second but as you can see like I mentioned these complexities continue to balloon so what we need to do is we need to say to the develop ER you only need to do two things effectively you need to sync AKA find all of your utxos that you can spend across all of the addresses you know about and then you also need to just send the value this should be a very simple interface for developers it should be me expressing my intention through your interface and my intention here is just I just want to send chi I don't care about the complexities that happen under the hood I just want to send it right and that's exactly what we do the interface for sending Chi is exactly the same as the interface for sending Qui there is no difference right and that is because we want users to feel familiar when using this product the next thing and this actually Builds on how we implemented Chi is in your tool set you want to be opinionated but you don't want to limit so what does it mean to be opinionated as a offer a product that is opinionated well when you offer a product product the default case or the easiest path is effectively your opinion on how the user should use the product okay and in my in my understanding of the opinion of how users should use your product that means it should be the most optimal case for a how your user wants to use it or in the case of maybe a public network it should be the most optimal use of this network okay and so with Chi like I mentioned there has to be a unique address per transaction output this means that even if I were to just want to send you five Chi let's imagine for example I only have I have five one Chi denominations so I'm effectively going to pay you you know each one of those one ches five times okay rather than me saying hey I need you to actually Supply me with five addresses so that I can send you these 5G we've actually come up with a solution that is much more elegant and better preserving privacy for the user that's our opinion that's optimal both for the network and for the user what this solution looks like is by effectively having a single payment code your payment code is effectively your identifier you could be thought of as almost one single address but we can use some fancy cryptography it's called um elliptic curve Diffy Helman which effectively says if you provide me this payment code I can derive addresses for you and then I can give you my payment code and you can then derive those exact same addresses that I just derived okay so what this means is we're no long we're not passing around you know dozens of addresses every time we want to send a transaction to anyone all I have to do is get your payment code I can derive your addresses right and there is one sort of hop on information exchange but that can be handled through smart contracts and done very s seamlessly so that is our opinion the best solution and of course like I said not limiting users can opt out of that solution they can go through the effort and the additional time to maybe make a worse solution but again it would not be optimal but we are not forcing you into a box to do it and last complement existing workflows this one feels obvious okay if a user goes about their day or it goes about their work in a specific pattern don't disrupt that find out where you fit into their workflow and build according to that okay and so how we did this is we actually said we have all this complexity but we don't want a user to learn another Library they already have ethers and they have VM and they have wag me right and the list goes on so we're like let's just Fork ethers let's get all of that complexity forced under the hood and let's give them an interface they're familiar with you don't have to go learn a new tool again all you have to do is just use a different Library same interfaces all new functionality so these are about the tools of today let's talk a little bit about the tools of tomorrow so we believe the tools are tomorrow make you build things that are more decentralized right if I'm building something on a blockchain network chances are I care about decentralization why should I have to worry about ether scan to get Contract abis why should I have to worry about infura being the only provider of data okay and these are not attacks on these These are fantastic services but in our industry it's don't trust verify we're putting a lot of trust into these people so for data providers for example I'm going to ask for some information about the blockchain state you're going to respond and I'm just going to trust you but there's no reason you can't lie to me okay so we actually invented this thing called neows or non-interactive proofs of proof of work and what Neo pals are specifically meant to do is allow you to verify the data you receive on chain is correct we build this directly into the SDK so the default path is now you this means any node can be a data provider okay this means that the SDK can route you to a decentralized set of nodes and validate that the answer they give you is true okay this is actually a very very sort of big deal in our industry because we have these very centralized roadblocks and this is how we break out and the next big thing is I uploading ipfs or utilizing sort of a decentralized data storage Network for storing contract abis okay so this is another thing that we've actually already done it's in production and it's a standard we've created so that when you upload a contract you first upload the API to ipfs you receive a Content hash and you appin that to the bik code in the contract that means if I have a contract address on Qui Network I can get the bik code I can parse out the ipfs content hash and then I can just grab the ABI directly from ipfs and I can know how to work with any contract on chain no centralized providers need it the next thing is we know we're in the AI era here of course everything is AI from Agents to developer tools to this the music we're listening to right now right and so what does it mean to build a system and tools that are ready for the AI era well number one's pretty simple just make your content and your docs indexable okay this is actually something that a lot of companies get wrong right so imagine you know you're you're using some very sophisticated um very JavaScript heavy fancy graphics for ad site it's actually very hard to web craw that right and it's going to be hard for an AI to actually use that information and embed it into the prompt for it to be able to give you a good response right and so in order for us to empower developers I mean I'm not sure how many of you guys are using tools like wind surf or cursor or repet or these tools that are helping us build but it is imperative to use these tools correctly you must have correct docks that are indexable by the tools okay so these are low hanging fruit but the next one is is actually preparing for the world or agents are doing the work okay what does that look like how do you integrate with that well first of all there's several actually kind of Crypton native AI Frameworks um we've integrated with a few but there's also really easy things you can do with um NPCs to be able to kind of work provide tools or common workflows to these AI agents okay so they can say well if I have the quii tool and you ask me to send Qui to you I can just very easily use the SDK to be able to squ without having to worry about it right and this is only going to get more popular we're only going to see more developers using these tools more AI agents performing these tasks so the Next Generation tool set needs to be built with AI and mind and we're absolutely applying this and building with it every day so I think we're right up here against time but thank you all for for listening here I think there's a lot of work to be done as a developer and as a builder I know that we are only as good as our tools and our tools have to continually be getting better until we fall or else we fall into sort of a legacy system here but I think we all know that's not where we are so again thanks everyone I appreciate the time again my name is Riley with qu Network please come visit our booth 521 where there's plenty more to learn and we're happy to talk about it thanks
Automatic transcript — names and jargon may be misspelled.