Near One: Scaling the Agentic Internet. AI X Crypto - Bowen Wang. Ep. 608

Transcript

Why crypto is generally interesting uh for like AI agents and so on is that it allows the possibility of AI agents to to own assets the monitoring means to actually do things. So we actually uh developed this thing called a shade agent which is roughly this architecture where you have this AI agent running uh inside TE trusted execution environment and it has this controller smart contract on near that controls its um access to different tokens and then you have this paradigm where AI agents basically running autonomously and can act on user behalf and do stuff with your assets in a non-custodial way. in the future there will be proliferation of those AI agents and you need a kind of scalable platform to to handle a lot of those transactions uh or interactions

between them. Uh so even just before this release we had uh about like 1.1 1.2 seconds block time and two to three seconds finality which was still faster than Sranos and and also faster than uh Ethereums. This release just allowed us to reduce the time uh by half which is uh even more impressive. Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization and the blockchain revolution. I'm Frederri an and today I'm speaking with Bone Wang who is the founder of um Near One which is one of the companies behind the blockchain uh which we will get into in just a minute. Before that, let me tell you about our sponsors this week. If you're looking to stake your crypto with

confidence, look no further than course one. More than 150,000 delegators, including institutions like BitGo, Panta Capital, and Ledger, trust Chorus One with their assets. They support over 50 blockchains and are leaders in governance or networks like Cosmos, ensuring your stake is responsibly managed. Thanks to their advanced ME research, you can also enjoy the highest staking rewards. You can stake directly from your preferred wallet, set up a white label note, restake your assets on IG layer or Symbiotic, or use the SDK for multi-chain staking in your app. Learn more at chorus.1 and start staking today.

>> Hey guys, I want to tell you about Nosis, a collective of builders creating real tools for real people on the open internet. Nosis has been around since 2015. In fact, it started as one of Ethereum's very first projects. And today, it's grown into a whole ecosystem designed to make open finance actually work for everyday people. At the center of it all is Nosis Chain. It's a lowcost, highly decentralized layer 1 that's compatible with Ethereum and secured by over 300,000 validators. So whether you're building a DAP, experimenting with DeFi, or working on autonomous agents, Nosis Chain gives you a solid neutral foundation to build on.

But Nosis is more than just infrastructure. It's also tools that people can actually use. Like circles, for example, lets anyone issue their own digital currency through networks of trust, not banks. And then there's Metri. It's their smart contract wallet that makes it easy to access circles, manage group currencies, and even spend anywhere Visa is accepted thanks to their integration with Nosis Pay. All this is governed by Nosis DAO, where anyone can propose, vote, and help guide the network. And if you want to get involved, running a validator is super easy. All you need is one GNO and some basic hardware. To learn more and start building on the open internet, head to nosis.io.

Nosis, building the open internet one block at a time. >> Loen, thank you so much for coming on. >> Yeah. Uh, long time listener, first time on the show. Great to be here. >> Fantastic. Maybe we start off with um kind of your uh super villain origin story. So, kind of how how did you how did you um break into crypto and how did you end up working on NI? Yeah, it's actually a super interesting story. Um, if for people don't know, Near started this AI company. Uh, I mean people often say Near are too early about things. Uh, they're very right. It's pretty much in the in the origin like back in 2018

which we wanted to do code generation. So basically uh back then it's called neurop program synthesis but basically the idea is that to translate natural language into code basically all the you know LM2s that that allows you to do it very effective today. Um but uh back then we were very ambitious about doing it and how I got into near is basically I saw a paper Alex and Ilia published at Iclear one of the uh machine learning conferences and I was actually doing very similar research um when I was in college and I saw their paper and I basically reached out to them uh and um yeah that's how I got into uh for for AI stuff um and uh yeah then we had this uh uh major pivot that happened in um August 2018 18 and that's basically the

start of a new protocol. >> What made you guys pivot from AI to blockchain infrastructure? >> Yeah. Um as uh also yeah I think actually wrote a blog post about this. I think people can still find it. Uh but uh let me just uh give a give a high level summary. So I think one thing is that back then uh it was indeed way too early uh for the code generation idea and um I trained some models uh just like the performance was uh was like not on the level where you can productionize this thing into product. It's like good research project and uh um but we estimated at the time that um in order

to get it to uh some kind of production level tooling, you probably need like a few more years of research and development. Um and and also uh it's really hard to compete uh with large companies uh just because of the um deficiency on on the data side. And uh at the same time uh uh we were looking at you know if we have this tool where can we actually first use it. So smart contract become uh one of the areas we look at and the reason is that at least back then I think still true today that smart contracts relatively self-contained right like lot lot of them are just few few hundred lines of code even less than 100 lines of code and um they serve like you know specific purposes that are relatively you know you can you can describe it pretty well

to some extent uh and I think basically we think that's a um natural first step to if we have this to actually uh apply Hi. Um and uh then we look at look more into smart contracts and then you know well how they actually work right what what powers them. Uh so back then um yeah Ethereum is pretty much one of the only uh power smart contract platforms and so we look at how Ethereum works and we saw that well there are a lot of things that could be improved and given um you know uh the Alex and I's background they they're like yeah maybe we can we can build something that u uh that results in a better smart contract platform. uh so like you know all uh all those factors combined uh led us to uh

to this uh massive pivot. So, in the time that kind of like you were you were busy building blockchain stuff, um all of that AI stuff has come to fruition, right? Kind of like in in some way kind of like you you pivoted to something that you thought would be faster, but then kind of like I mean blockchain is still much further away from the mainstream than say Chad GPT. And I mean I I know Elia was also instrumental in the transformer kind of like the transformer model. So, um, was there ever any FUD as to kind of whether this whether this pivot was well timed and well placed?

>> Um, I don't think so. I think uh I think it is it is a good pivot because uh you know we we have built uh one of the one of the best uh blockchains out there and we're quite successful in in in this area. uh and even if we uh marched along the the I road uh what will very likely to happen is that we won't even like we won't be able to comp still compete with those uh large companies and maybe what will happen is that we run the funding before like the uh the LM board actually comes along in 22 right so like it's really you need to like go through those dark years before you see um light at the end of the tunnel um so I no I don't think so I think I think we all think

it's that this this is the right decision that we make. >> Cool. So, we said in the intro that you are um the founder and uh and CEO of NI1. So, what does what does NE one do and how does it kind of fit into the NIA ecosystem? Because there's also the NIA foundation and Pagod, right? >> Uh Pagoda no longer exists. Yeah. So, Near One is basically the the entity that uh uh does uh technology uh research and development in the near ecosystem. So we work on obviously protocol research development but also we built uh technology on the chstruction stack uh including chain signatures and uh omni brbridge uh so basically to uh provide this uh unified experience uh to end users uh regardless

of uh what blockchain they want to interact with. Um yeah that's basically a summary of what we do. >> Cool. So maybe let's dive into the tech. So, you guys recently announced um an upgrade that lets you have 600 millisecond block times and 1.2 second finality, which is insanely fast. So, it's kind of like 10 times the speed of Solana. It's um well, depends on kind of like I mean finality and Ethereum are slow and kind of like you can do things beforehand and so on, but kind of like in terms of finality, it's 600 times faster than Ethereum. So kind of walk us through the technical um requirements and kind of the technical stack that

makes this possible. >> Yeah. So I think it's actually not just uh any single optimization or any uh single uh feature that we implemented uh that led us to this point. I think it's uh ensemble of uh different techn technological improvements uh we made over the past uh several years. Uh so even just before this release we had uh about like 1.1 1.2 seconds block time and two to three seconds finality which was still uh pretty good right it could it's still uh finality is still faster than Sranos and and also faster than uh serums and this release just allowed us to um uh reduce the time uh by half which is uh even more impressive. Um so I think um yeah I can I can first talk

about what we did uh in this release specifically and then I can talk about um things some of the things more general that we've had for for a long time. Uh so in this release um I think it's it's actually very interesting uh story because uh when we launched uh NJ 2.0 and also basically make the system fully sharded and also a stero validation design uh back in August uh 2024. about a year ago um we actually uh undid a um an optimization that was originally in the system um that that you know supposedly led to longer latency but because we actually in that release we significantly improve the latency um by actually holding u basically uh holding

the state of uh of each shard in memory. Um I can talk more about how how that actually is possible. So we actually uh like netted some improvement in that regard. Um but still we had this problem where like um in the old design what happens is that uh you as a chunk producer so chunk producer basically um uh a block producer for a specific shard. Um so when when a trunk producer produces a chunk it doesn't apply it immediately. it it first sends it out to all other um validators trunk chunk producer in in the system before it even applies it. So this is notably very different from I think all pretty much all the other blockchains I know because

like if you look at how Ethereum works, how srano works, what they do is that you always have post stage root meaning that or srano doesn't have the stage root for every block but um but what what what it does is that you first uh you you as a block producer you produce a block and then you apply it and then you you you kind of have the the actual block with the post which state of after this block. uh but what do we do is different we we use uh prefate route meaning that in the block what it basically says that what it what is the the state route as of before this block so we don't actually need to apply it um before the block can be produced. So this allowed us to do this interesting optimization where like we disseminate the chunk before the block producer even

applied. So it means that uh the application of this chunk is actually parallel in the system. Pretty much there's um uh no overhead as to like the other guys need to wait for this producer to to apply this block before they can apply the block. Uh basically you know ignoring some some network latency then basically everyone applied at the same time. Um and this basically makes make it make it much faster. Um and we undid that in the night 2.0 no launch because now we actually need state witness for each uh trunk meaning that you actually uh need to present this uh Morco proof um of the state uh so that the validators can actually

validate it. So you cannot just say like okay I produce a a producer produc a chunk and I disseminated right away because you don't have state witness so that doesn't work immediately. >> There's a lot to unpack here. So maybe let's start with um kind of the way that the network is architectured. So kind of in um in Ethereum kind of there's kind of there have been very long debates about kind of how long block time should be and kind of to to optimize it um such kind of that kind of like network splits are reduced right so kind of you want to make sure that kind of the block kind of propagates through the network properly. Um why is this different for you guys or is

it different for you guys? >> Um I don't think it's really different and I also think that there is no fundamental reason why is block time has to be 12 seconds. um I think it could in fact be much faster that I mean that is what people are discussing the states right so um I don't think there's any uh fundamental limitation either on you know network bandwidth or um some like you know the the round like the how fast it takes to to to actually apply a block and and so on in fact the I think the Ethereum validators are trying to raise the limit to 60 million gas um so I I yeah actually I I don't have a good understanding of Why why set to 12

seconds? >> I I think Yeah. So, actually I think I remember I think kind of like it's from when we still had um uh a proof of work. Uh because kind of then kind of you kind of needed to disseminate the the block basically because you didn't know who was who was allowed to build the next block, right? So kind of and then kind of you had big anchor rates kind of like if you had too slow propagation. But you're right kind of like for for obviously if kind of like if you have uh if you have uh proof of stake then um that shouldn't be um an issue. Um so what what are the requirements for running a node? How many how many nodes are there? Is it kind of something that

a hobbyist so kind of like I run an Ethereum node and kind of like I'm I'm I'm not a professional DevOps person. So kind of um and for me that's possible where whereas kind of like there's no chance I I could ever run a Solana node for instance. Where where does NIA sit on that spectrum? >> Correct. No, I think that's al also like one of the things that we really value, right? the ability to uh for um everyone to to to run a node and um especially a a node that participates in the consensus uh because we think it's uh important for the decentralization of the network and and actually um the the recent data we got is that it takes uh $27 a month to to operate a near chunk validator. Uh so this is because after

the stir validation uh change that we launched as part of 19.0 No last year the validator don't need the they don't need to store any state locally. So uh they they validated by having this state witness. I mean the uh we can talk more about the stress validation design but this was actually Varic's original idea he uh he put forward in 2017. Um and uh it is really for it is really beneficial to the decentralization of the network. So now you can actually make the node super lightweight because it doesn't really need to have the state. I mean state would be the most um expensive thing you already know node has right that like take take up a lot of a lot of disk space as as well as potentially memory but because we don't need to have that you actually get state witness on

for each block um and then they validate based on that uh and then they can throw it away afterwards. Uh so >> yeah maybe maybe maybe just to interject here just to kind of I'm not sure whether everyone's familiar with the term so kind of like stateless validation it just means you don't need the entire state in the memory but kind of like you just need um the the transactions that you're processing and kind of the previous macaroot and the and then kind of you can you can you can see that kind of like this is this is fine without actually knowing and I mean obviously the state is massive uh depending on yeah so >> correct yeah yes yeah so so just uh to to kind of yeah I should have explained the how state witness works. Basically it's a it's a proof that uh the the uh

state that the transaction touched during the execution uh indeed belong to the to the previous state. So there's like it the the producer the chunk producer in this case is not being malicious because you can actually verify this indeed belongs to the previous state route and you can also verify that um as a as a result of processing this chunk uh the post state route actually match what they say it should uh it should be uh so that this state transition if is valid. Um and as you said um the uh the the kind of the key insight here is that even though the state itself can be very large uh what you touch during the execution of one block is limited. So you can actually have this rather small uh state witness uh that is is distributed to the

validators and they can validate uh validate the state transition based on that. >> Okay, I understand that part of the optimization. You also touched upon something that I didn't fully grasp earlier. Um so that was the fact that kind of um validators send out um blocks before kind of they apply them. >> Yes. >> Can you explain why that why that is secure or kind of as as as a near validator? Is there any any way kind of I can uh I can use this to attack the to attack the network? So kind of why why what's the special thing that kind of

allows NIA to kind of propagate these blocks before they've been um >> Yeah. Yeah. There's nothing about really about security here. It's it's mostly about this concept whether you you're using um previous state route or um post state root. So So okay. Yeah. This is a bit tricky to explain. Uh I'll try my best. So in Ethereum how it works is that you you need to have a um in order to produce a block uh you need to actually say like what is the state root as of after applying this block. So basically the block producer need to have the block it depends the transactions uh or like some some builder send them transactions. They need need to apply they need to say like okay as of applying this block what is the state route uh afterwards right? So

then they have the same hole together as the block and then they distribute that and then people buy it. Now uh in here what we're what is different is that um each block doesn't say what the post uh what is the state route as of after applying this block. They just say what is the state route as of before applying this block. Uh so um because of this shift uh the kind of the things on the consensus level doesn't really change but but it allows um it allows the validators to to to kind of instead of kind of applying it first um they can they can they can send it out and um uh and then like everyone applying at the

same time and then basically like as of like um as they're endorsing this block they're endorsing basically what the previous state of this block is and and is always shifted by one in in that regard. >> Okay, I I understand that. But are there any disadvantages or why don't other blockchains do it like this? >> Well, actually I think I think I'm blanking on on the reason, but it it has something to do with the the synchronous execution uh nature that uh that that EVM and other chains have. >> Okay. Yeah. Do don't don't worry about it. So um m maybe maybe tell us about um the asynchronous um uh execution in near so kind of like h how how is it different for you guys?

Yeah. So so on near how it's different is that uh so let's say you have one smart contract that's calling another smart contract. Uh then um you know the how this works is that this call would be synchronously executed in one block. um and um um and and then you'll get the return result. And now near how it's different is that uh those two smart contract can live on different shards and because they can live on different shards um um you cannot actually have this uh synchronous execution directly. So what actually happens is let's say uh you have some smart contract A uh that's that is being called and then it generates u another call to smart

contract B and um um what what actually happens is that uh there is some block where the smart contract A execution happens and it generates a receipt that sends to the shard where the smart contract B is on uh and then the execution would uh continue there but the will not continue in the same block it will continue uh for example in the next block. >> Okay. Yeah. So, I think there's a part that we kind of glossed over earlier a little bit and that's the the um the part that NIA has full sharding. So, kind of you you you kind of have full execution sharding kind of the way that kind of um uh we thought originally kind of it would play out um for Ethereum in

the in kind of like for scalability. And I mean that's still the plan, right? But so far Ethereum doesn't have it. So kind of like you have you have um different execution shards that kind of talk with each other with that kind of that talk with each other asynchronously. Um so um tell us um how how the how that's architected and how you would compare it to other um kind of federated um chains such as kind of like the IBC ecosystem for instance.

>> Yeah. Um so it's actually pretty different um paradigm there. I I think the uh so so what near allows is basically this uh native composibility between different shards meaning that um if you want if you are a smart contract uh on let's say shard A um you want to call some smart contract on shard B or some some smart contract on shard C you don't really care about it you just call directly and then developer don't even think about when they when they develop the smart contract um but um um uh and and basically yeah smart the de developers also don't really think about which shard they deploy this their smart contract on. It's basically the system automatically figures out uh which shard

um on uh the uh the smart contract is on and basically this sharding is transparent to the developers. They don't really think about this. >> But h how how does the system kind of figure out which shot my smart contract should be on? Right? because kind of like it kind of like if I call if I interact with um a specific set of smart contracts um that are all on one shot um kind of I can do that synchronously if I'm on the same shot right >> correct no that's actually not not true so that's not true system yeah the system is completely as this is so that we don't encourage developers to try to figure out how to colludate their smart

contract so even if Okay. Interesting. >> Yeah. Yeah. And and another reason another reason is follows. So we have this mechanism called resharding, right? So this is a mechanism where you split one shard into two shards. And the this this could happen because one shard is overloaded, right? You you want to u you want to kind of have a way to react to that. And it basically there's this mechanism can split a shard into two shards. And if you if you actually depend on the collocation of two smart contract on the same shard then like you know this mechanism potentially break it and then it's really bad because let's say you you depend on and then one day you discover it's actually not on the same shard then then like you your assumption um you know let's say we had synchronous execution and then suddenly

not become asynchronous and it might potentially break a lot of syncs. So that's why we decided to basically stick to the to the async execution paradigm. >> Okay. So basically the and then kind of like when you split them kind of like you you more or less decide um randomly which bits of the the how how the shard is devied up. >> Uh it's not random. It's basically based on like gas usage and state size. So roughly you you can try to find the the middle. >> So half and half. >> Yeah. Yeah.

>> Okay. >> Obviously it's discreet. So you cannot like make exactly 50/50 but like Yeah. Rough. Yeah. >> Okay. So, so talk talk about how these different shards manage to communicate with each other. >> So, so basically the the concept is called receipt. So, let's say uh you have smart contract shown A, you have smart contract short B then they want to communicate with each other. Uh so there's obviously on the smart contract level developer just write I call that smart contract. What actually happens is that uh there is a receipt that that's generated in the system that's going to be sent uh to the destination shard. uh and then um on every chunk which is a short block uh it says what is the uh

the outgoing receipt route basically it's a mer route of all the uh all the receipts and then uh on the on the destination shard they can check that uh it's indeed there's a merke proof basically allows the trunk producer to check that it's indeed coming from the other um the other shard and uh uh like the it matches the outgoing received route so that everything is uh like there's no receipt that being generated out of nowhere right so everything is basically uh matches uh correctly. Um and then there's a mechanism basically for um the chunk producer of one to basically uh get the receipt uh from other shards. Uh so they actually fetch them uh so that they would get it for um uh basically after one block uh they

they would get them. Uh so yeah, this is kind of on on the high level how uh how it works. Obviously they're it's it's um it's kind of complex in in the in the details. Um but that kind of conceptually how how it works. >> Does every shot have a complete list of all the other shards? Um and if so, how is it updated? So kind of like if I'm a shard, how do I know I'm actually getting um information from a legitimate other shot? How do I know kind of like someone's not just sending me a message?

>> Yeah. So the coordination of all shards and validators is global basically. So uh all the valid data understand um globally what is uh how many shards there are uh and then at every block uh who is producing for for that shard and uh oh I think I think I forgot to mention this part uh one of the key uh maybe one of the key innovations of uh nade originally design that there's only one chain there's no separate blockchain per shard uh but and then each block uh contains um the header uh of of every chunk from every shard uh So obviously you cannot put the entire chunk into uh into blocks because that would be humongous. Uh so what actually happens is that each block contain all the uh

chunk headers and then people actually reach consensus on that and that's how you actually know that what what is actually the uh various roots that from other shard uh because it's it's included in the blog and then everyone has access to block they're relatively small uh and then the the entire address which consensuses on on the block. So that's how they know that uh yeah those are legitimate information. >> So I understand why you're setting up setting it up such that developers don't try to colllocate their smart contracts.

Um but that also creates a lot of overhead right kind of like if if you kind of think about um kind of team communication or say kind of like say I mean it's in in essence kind of it it it kind of increases the amount of message passing that you kind of have to have between the shards a lot. So does that kind of um I mean kind of if if you think about it kind of in terms of super naively and kind of like say okay every smart contract is kind of like a person um kind of doing some work you kind of you want to colllocate teams together so that they can kind of talk with each

other and don't need to send each other letters right and in a way kind of you're you're kind of you're you're enforcing remote work for everyone Um, and kind of you're you're making everyone send letters just so doesn't that kind of make the system less efficient than it could be? >> I think uh there there's definitely like an argument uh for that. Uh but I think you know there is fundamentally a balance between um kind of I would say uh scalability and um um maybe convenience or uh you know you could say

like latency of execution that that that needs to to be struck. Um and um I I I wouldn't say the there's a lot of overhead in this because let's say if you compare what we I describe to basically a system where you have uh synchronous execution within a shard um the the kind of messaging overhead doesn't really uh increase that much because um for um you know if if there's some receipt going from uh the the shard to the same shard it doesn't really send external messages Um it it's just like they they all the chunk producer know after they apply the uh the chunk what which shard the receiver will go to. If

you go to the same shard then they don't actually need to send it out to to other people. They they all have the information. Um but yes you're right in the sense that this does mean that initially executed in the next shard instead of in uh in the next block instead of in this block. Um but I think um it is a highly de debated topic even even within the team. Um, I think it's it's basically like, yeah, do do you allow people to have the convenience or I guess maybe not necessarily convenience is the right word. It's more like have the ability to um to kind of unlock this synchronous execution partially or you stick to a paradigm where it's like um from like design level is like uniform. You don't really

need to think about the special case. Um I think we've we've taken the the latter approach uh just because um from the design point of view it's um um you could say synchro because you you don't really have any like special case uh in that regard and it also as I said it works uh well with uh things like you know what do you need to do with resharding and and then so on um and um I think we are like actually uh have some ideas about potentially allowing um multiple smart contracts to be on the uh same account so that you can have kind of synchronous execution within uh those smart contracts. Uh so yeah and and and actually that's how basically how kind

of how Aurora works. It's like a EVM uh interpreter running a smart contract on here and then it internally holds a bunch of EVM bite codes and it can then do like synchronous execution uh between those smart contract completely emulating the EVM experience. Mhm. Tell me a little bit more about the shards. Are they all created equal? So, kind of um is is for instance, is uh gas the same cost on each shard? Um kind of do they all have kind of like in principle the same uh size limit um and so on.

Because in principle kind of like you could almost imagine it like like real estate where kind of you say okay one's kind of like the premium premium chart and then kind of like you have um uh lower um uh yeah lower tier real estate elsewhere um where kind of kind of rent is cheaper and kind of uh but yeah I mean in princip and I mean kind of like we we've seen this kind of like with um kind of like parameterization of kind of different execution environments on on in other ecosystems. So um uh tell me kind of like h um what path you you chose and why you did so.

>> Yeah. So um yeah that that's uh that's also another very interesting question. Um we we basically we we we chose throughout that uh all shards are created equal uh you know in terms of gas limit uh you know like how how they work like various things there's not really no like and no shards are really special uh in a sense um and again I think it comes down to the philosophy that uh we really want this to be transparent to developers um they don't really have to care about uh which shard their smart contracts deployed on um and they really don't really think about sharding when they do smart contract uh development. Uh they just know that uh

they write some code that could be compiled to web assembly and then it will be deployed uh on their account and then magically it will work. Uh so I think from that point of view uh it definitely uh reduce a lot of uh uh cognitive barrier uh for smart contract developers. Um and um uh it it also allows us to um if we think about like how how it scales, right? We scale through having more shards. It also allows you to not having to deal with like um some special cases where like maybe we can scale some shards but not other shards. It becomes really strange um and really just uh uh hard to deal with from a design point of view.

>> I understand the trade-off uh that that that you're making. Um tell me a bit more about um stateless validation. So kind of um I I understand um why this is clearly superior. Um but te tell us about kind of uh the technical lift that you guys had to make to kind of uh implement this. Why why don't we have this yet on Ethereum? I I actually think someone developed a steerous client for forum but uh um it that doesn't get adopted because um u not not sure why exactly uh but I think um forum today to um transition to

stress validation yeah probably involve a lot of uh uh well okay I I I should say like I probably don't know well enough to to understand all the things that may break um or the problems that may create. Um but uh I think yeah I think I think for near uh one of the um I think it it's almost uh um you could say um yeah so so it benefits us in many different ways right so one one is that it makes the um the sharding design uh kind of more uh simpler in the sense that um now with uh serious validation we can have validated

rotation on every single block. Uh so we don't uh we don't have to worry about uh the security problem that you might address with um uh fraud proofs and so on. Uh because yeah the validator rotate on every single block. Uh it is um basically pro probabilistically uh the uh basically pro probabilistically every shard is secure because the the assignment is is random based on this random randomness beacon. Um and uh they rotate on every single block. Um uh so that that makes that simplifies uh a big pain point of the design. Um because if you think about uh what uh optimistic rollups are doing

today uh the fraud proof is still like I was not not completely I mean it's not kind of resolved from the technical point of view but like it's really scary to turn it on and and uh uh I think still like no major uh L2 uh have completely turned it on uh in a in a permissionless way. Um yeah so so that that was that was also uh yeah scary for us as well and uh I think even compared to our two zero like more ways like that can be messed up uh in our case so it's even even more scary you could say um because you need to think about um like what what do you do with the rest of the state on other shards uh you need like basically simultaneous state roll back all shards which is quite annoying um so

yeah so that's that's one one piece and another Another big piece is that uh what I talked about initially which is that um it actually it actually works really well with sharding in the sense that um because we have we have sharding we can limit uh the size of each shard to some reasonable number let's say um 40 gigabytes or 50 gigabytes and uh you can have this dichotomy of uh chunk producers who you only need a relative few of them because you cannot do anything malicious. they they exist for censorship resistance reasons. Uh so they can run more expensive hardware and you can have a lot of validators. They actually collectively validate the state transition but they don't really need to

run uh any expensive hardware uh because they receive state witness which are relatively small. So now you can have this dichotomy where you have on the one hand you have this chunk producers that can run uh relatively expensive I wouldn't say super expensive it's still consumer grade let's say 64 GB of RAM so that which allows them to completely hold the state in memory as they are executing the uh the the chunks so that would be that would be uh really fast and then on the vitor side because they receive uh state witness uh that are relatively small they also uh when it comes to execution the state is also held in memory. Uh so this actually addresses uh one of the biggest performance bottleneck that we had

before uh that comes from uh state access because um as you know like you know when you have a database um whether it's like level DB or like rox db or anything like that you cannot guarantee really like uh fast execution uh for every state access is like not possible and and some of them u and then some of the state access will potentially become quite slow uh if you miss uh miss the cache um and that actually become um that and that means you cannot really uh reduced the the gas pri gas cost of certain operations. Um and yeah, that that was actually a big performance bottleneck for us. Um and uh yeah, then this basically addresses that major performance bottleneck. uh and and it really and works really well with

sharding because as I said if you if you don't have this sharded setup you only have um you know let's say there's no no concept of sharding everyone needs to all the producers need to track the entire state then at some point it probably become unrealistic for you to hold let's say um 300 gigabytes of state in memory. Yeah, absolutely. Cool. I think kind of we've talked about a lot of the tech stats. Um maybe let's talk about um the kind of applications that kind of you're starting to see with finality this fast because in in some ways um it it's a paradigm shift in kind of what you can

actually run on blockchains, right? >> Yeah. Yeah. I think exactly. I think so if you look at uh a lot of the application on near uh there a lot of them are um consumer focused um and though we're seeing more and more uh kind of ch abstracted ab uh applications that are working on near uh so you know the uh some of the largest application on near including uh kaiing which is this uh um this like kind of a platform that allows uh users to earn points by uh watching ads on on their phone and also sweatcoin which is a work to earn app and uh in a lot of consumer applications like people care like they they they don't really care about what blockchain it runs on even whether it

runs on blockchain but they they do care about like the experience the end to end experience they get right so when you have like uh faster block time faster finality that's definitely very beneficial to them um and also what we're seeing is that uh with those um chain abstracted applications that settle on near for example we have near intense is one of the uh decentralized uh platform for multi-chain asset trading that we're seeing on here. Uh the the extremely short uh finality really means that it can settle really really fast and uh that is uh very very appealing to people as well.

>> So the the crowd that really you kind of have to convince to build on developers, right? Kind of because as you say um users are not going to care, right? kind of like I mean we we we we care we because we've been in this in this ecosystem uh for a long time and kind of like we we're interested in the tech itself. Um but this is very much not a regular user right kind of um all of this will be abstracted away from the user. So kind of what are the value propositions that you have for the developers? So kind of like why why why why would someone say okay I'm I'm building this application on NIA rather than on Solana on Ethereum.

>> Yeah I think definitely the uh the kind of block time uh fast block time fast finality is uh very appealing to them especially in certain financial use cases where they they want to make sure there's a fast finality guarantee that there's there's fast finality guarantee that you know the transaction has already happened has been settled. Um but but also like the the cost is another uh big consideration for them right the uh if you compare the cost on year to cost on Ethereum there's like a pretty big difference and the the basically the uh the cheap transactions uh is another uh appealing factor for the developers uh and now with the work on uh more on chain abstraction uh we also like developers think about uh what they can access from near uh this kind of into this uh multi-chain world I

think that that's another uh appealing uh factor to M >> you talked about the um intentbased infrastructure um tell us a bit more about that. >> Yeah. So so basically the the idea is that uh so we have built this uh um intense based uh uh decentralized infrastructure for right now for uh multi-chain assets uh trading and settlement. uh but it's pretty general purpose and you can uh it it can potentially be used uh for uh se like kind of a uh slow settlement or like clearing use cases uh but also uh potentially settlement of uh physical goods trading as well um eventually and

we we kind of we kind of envision this to be um this settlement layer for uh for this uh internet commerce eventually uh because like a lot of things a lot of different can be expressed in intense but obviously to get there you need um more complex system that involve like uh arbitration like you know what happens when there's dispute and and all this kind of stuff so right now we're uh it's started this uh uh this multi-chain um as a trading platform uh so basically you can uh it's currently an RFQ platform where you can say like I want to trade one bitcoin for one ethereum please gave me a code and then there are a bunch of solvers uh which trying to solve uh for this code and provide the

user with a code and then the settlement happens uh on near uh inside the smart contract. So basically when this uh when this intent is executed the smart contract is updated and um uh yeah uh happens really fast. >> I've used it. It's super impressive. So I I was totally blown away. Um but it seems like there there isn't um uh there isn't >> all that much usage yet. Why why why do you think that is? >> A lot of it is related to distribution.

uh you need to get to the right uh distribution channels uh because it's not that u uh you know if you think about what people do today they uh they you know a lot of let's say they want to um get uh uh token swaps and so on uh outside of centralized exchanges where what they usually do is that they they go to the wallet uh a lot of the wallets today have built-in swap functionalities and they just do it there. Um so it's it's uh if if you have like completely new platform it's really hard uh to get uh just a good uh amount of distribution and that's why we're partnering with different uh distribution uh channels and we had a kyber swap integration life uh and there are a few uh large ones

that are in in the pipeline. So um I think yeah if we get to um get integrated with uh a number of major uh wallets and other uh similar distribution channels then that's where we'll see a lot more usage. >> Mhm. Yeah that that that makes sense. Um you also kind of have kind of despite the fact that kind of like you initially pivoted away from the AI angle kind of is known as kind of like the AI agent blockchain in some ways. um why why are the um fast block times important for AIS or kind of like what are the use cases you guys see?

>> I think a number of different uh use cases and I think one is this uh kind of uh autonomous AI agents uh that we're thinking about. Uh so it's actually a a pretty uh interesting paradigm where you can have uh well so just just to start um I think uh why crypto is generally interesting uh for like AI agents and so on is that it it allows uh the possibility of uh AI agents to to own assets uh to have uh the uh the monitoring means to actually do things uh because if you think about the the traditional uh financial system it I think it's very very unlikely that AI agents can pass KYC and get bank account and so on right so so crypto in that sense give them uh this unique uh

advantage that where they can actually own uh assets and uh um do things with them um and I think uh on specifically uh we're working a lot on so we actually developed this thing called a shade agent uh basically which is that which is roughly this architecture where you have this AI agent running uh inside uh some uh TE trusted execution environment um And it has this controller smart contract on near that controls its um uh kind of access to uh to to different uh tokens uh basically what it can can do which um uh what what kind what token the the agent can control. And then you have this uh kind of paradigm where uh the AI agents basically running

autonomously um and uh kind of can act on user behalf um and do stuff with your uh with your assets in a non-custodial way. Um because the the the reason why it's non-custodial is that uh anyone can spin up uh this uh this agent and if the agent is inactive the user there's a way for user to withdraw the the phone. So there's no uh worry about loss of funds and so on. uh and this give rise to some uh uh I think very interesting autonomous uh uh AI agent uh use cases where it's like u uh it's not really run by by any controlled by any like uh corporation government and so on almost like exist uh completely indep independently uh and and just like acts

according to some program uh and does things uh so I think uh that that's potentially a very interesting use case um and uh and we also imagine that um just like to to kind expand on the on the AI agent uh use cases. Uh we expand we expect that in the future there will be uh uh basically uh proliferation of those AI agents and uh like you know even one user may have uh many of them and uh you you basically need um and they would like trade uh between between themselves or uh do other things uh settlement and and and whatnot. uh and you need a kind of scalable platform to to handle um uh a lot of those uh transactions uh or interactions between them uh yeah

whether that's financial or otherwise uh so I think that's why um you know it is important to have this uh scalable blockchain that is fast and also cheap uh to enable this uh uh a lot of the AI use cases there >> does putting AIS on a blockchain that you can't stop worry you is do you find that worrisome? I think >> because kind of like, you know, kind of like in this entire AI doom kind of um discussion kind of like a lot of people kind of just end up saying, you know what, if they turn on us, we'll just

pull the plug. >> And this is something that's that's kind of that's precluded if you kind of run them on unturnable infrastructure right? >> Yeah. I I would say like uh I mean the first thing I would say is like you cannot really stop that from happening. Um it's uh it's like uh the technology is is there and uh it will u it will make progress um and uh I think it will happen like one way or another. I think uh instead of like uh purely worrying about uh what that consequences may be I think we should actually actively explore the the frontier of the technology and understand uh what benefits we can get uh from having uh

such paradigms. Um and um you know in in a lot of the technology revolutions in the past um people are always afraid of the the new things new possibilities. Um but uh I think it turns out that uh you know we we've benefited a lot from uh the advancement of technology in the past several hundred years >> that that may that's true but it may also be kind of like uh selection bias right so kind of like had we not we probably wouldn't be talking here. Um >> fair. So um there there's a lot of stuff going on um kind of in NIA's ecosystem, right? So kind of like you have AIS, you have DeFi, um we talked about those, you also have an NFT ecosystem, you have

Dows and so on. What what do you feel is working and what what's been harder than expected? I think uh you know what is working is that we've seen that uh we've built this uh uh very scalable blockchain this smart contract platform that actually has a lot of usage and it doesn't crumble uh you know under this heavy pressure I think uh we have like about uh 3 million daily active addresses uh and sometimes um 10 million uh transactions a day um and uh some sometimes even more than that uh and then we're seeing that uh uh the shing architecture actually works well. So there was a time uh I think in 24 so last year where there's sudden increase

of traffic on the network and we were able to address it by uh splitting uh some shards into two shards and we've actually seen that you know this does actually address uh the network uh congestion problem um and that gave us uh validation and uh hope that uh you know we're on the on the right path. uh this is you know how you you can address the scalability problem for uh blockchains and it is uh uh and what we we've built have uh proved that point um what has being more uh difficult um I think yeah I think on some of the um on some of the AI use cases it's um it it's uh uh not that easy to to build out uh

the the product that that people U for example uh you know we talk about uh uh confidential model inference and and model training the the I think those are like very um great uh technological promises but they do take time to uh to realize and I think it's just that there's this m mismatch between you know what people expect versus uh you know how fast that can actually be done uh because some of those uh I would say like hardcore technology does take time to uh to get built uh just like sharding it it took a number of years.

>> Yeah. So in in building such a complex um protocol um are are there any decisions that kind of in retrospect you wish you would have taken differently or if you had to if you had to do it over? I mean you can't you can't really change it after the fact, right? kind of like if you had to do it over is there anything kind of like where you say h I I would have decided this differently. >> Yes. Uh so I would say the how the um yeah a couple of things. So one one is like the uh I think a big one that comes to mind is how the uh storage um the

storage mechanism or storage economics mechanism works uh on near. Um so I I know that you know this is also debated in the Ethereum community like you know the I think there was change right initially you have this uh you burn uh your gas and then you get storage and then there's this refund mechanism and then people people abused that in very in very interesting ways and uh um and yeah so on near um we initially had a storage rent uh idea that actually I think Salana uses today um but Then that there was basically some problem that we observed. So we decided to switch to the storage staking mechanism. Basically you need to lock token uh for storage and

then uh when you um uh like if let's say you decide not to use storage you can like remove the the data and then you get the token back right. So basically you just log it for the for the time period that you want to use the token. So the the I mean that I mean sounds sounds reasonable. The problems that in reality people don't really delete much data from the blockchain. Um and I mean that by itself is okay. Um but it actually creates this uh developer experience problem where uh a lot of times you need to like um deposit some token into the smart contract to pay for storage because obviously you cannot just like make smart contract pay for every user storage. I mean that always your factor of tag. So now now it

becomes this uh the developer have to deal with this thing where like on on some like you know smart contract cost the user needs to attach storage deposit and then they need to calculate how much deposit they need to attach exactly to pay for the storage and that has been a common uh pain point for uh for developers. Um, so yeah, I think that is definitely something we uh we kind of regret in retrospect and this is something really hard to change because if you change it pretty much breaks everything. >> I see that. Um, is there a way to kind of just automate um kind of the calculation of how much you kind of have to deposit?

>> Yeah, the problem is sometimes dynamic. It depends on the payload. >> Okay. >> If it's completely static then yes. Yes, I think that's less of a problem. But yeah, the problem is that sometimes like one smart contract cost another, they need to figure out how much token they attach to call the other smart contract and things like this becomes very annoying. >> Oh yeah. Yeah. I I I see that. So kind of zooming out from today if you think about kind of like success for for Neil um in say um a long time kind of in in blockchain terms. say uh 5 years what does success look like for you guys?

>> Yeah, I think uh basically we have this dream of uh making uh you know user owned AI or user owned uh internet basically uh having uh near be a core part of the uh the new paradigm of how internet is going to shift. Uh so basically we believe that the future of interaction with internet will be through uh some kind of AI interface rather than through a browser. Um and um uh basically we're building this entire stack from uh you know the protocol to uh you know the intense framework uh to various like AI uh infrastructure and application that uh we hope that can power this uh future where people interact uh with um with internets through their uh AI system and we want we want people to in in that in that

word we want people to control uh their data have their own like a system that works on top of their data and versus instead of having everything being controlled by certain large corporations. >> Mhm. Yeah, that's uh that's certainly a good vision. And I I think kind of like if you look at kind of the the the way the internet is going, it's it's much needed, right? So kind of if I if I kind of had a crystal ball um and I were to I mean I were to tell you kind of this doesn't materialize.

What what do you think the root cause will be? >> I I think I think could there could be many but I think one of the big ones is um that many people believe that um the uh the kind of uh the large AI companies today uh have already reached some kind of escape velocity. uh that becomes really hard to uh turn around and have uh like for example uh open source version that can like meaningfully compete. Um and um I think re a related point is that today there is no incentive structure for open source or AI and they're basically like there it's not not just that they're behind but there also no incentive to really uh

push it forward and compete uh with the biggest company there and then that's actually one of the things we wanted to solve with what we're doing on the on the AI side to have the proper incentive mechanism that blockchain can provide uh for like model training and and finetuning and so on. Uh but yeah, it's definitely like um some people would say that you're completely crazy like how how is it possible that you can like you even imagine that this is this can can be d right. So I think uh that's definitely uh a possible way to fail. >> That's a little bit of a daring note to kind of end on. Um so but I I think kind of like asking yourself if this doesn't succeed,

what's likely the cause? It's often a good way of kind of addressing kind of the the the potential flaws in the system, right? Um so where where do we send people who are interested in um using NI building on NI um kind of learning more about NI? >> Yeah. So go to near.org. Uh it's our website. We're actually uh in the process of launching a new website that will have uh more content about what we're doing on AI on CH abstraction and and so on so forth.

>> Cool. Fantastic. Thank you, Bowen. It's been an absolute pleasure. >> Thank you. Uh really appreciate you uh having me on.