Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Alex Skidanov & Illia Polosukhin: NEAR Protocol – Scaling Blockchain to a Billion Users

Episode Date: February 19, 2022

NEAR Protocol is a leading smart contract platform that aims for simplicity, security and scalability. NEAR was one of the first sharded blockchains and allows deploying smart contracts using Web Assembly on currently four different shards. NEAR's sharding design, Nightshade, splits the blocks into different segments, which allows for great scalability without negatively impacting user and developer experience. Since, its launch NEAR has evolved into one of the most active smart contract ecosystems.Illia and Alex, co-founders of NEAR, joined us to chat about the NEAR's protocol design and recent advances, such as the launch of Aurora, NEAR's EVM shard. We also discussed how their sharding solution works and how it can scale to support a massive amount of users and applications.Topics covered in this episode:Why Illia and Alex decided to build NEARNEAR's core idea to scale through shardingNEAR’s Nightshade sharding designDealing with interactions between programmesHow cross-shard interoperability worksAurora - the EVM shardNEAR's focus on user experiencePagoda - the first web3 startup platformThe biggest challenges aheadEpisode links:NEAR ProtocolAuroraNEAR on TwitterAlex on TwitterIllia on TwitterSponsors:Gnosis Safe: Gnosis Safe is a smart wallet for securely managing digital assets and allows you to define customized access permissions. - https://epicenter.rocks/gnosissafeTally: Tally is a new wallet for Web3 and DeFi that sees the wallet as a public good. Think of it like a community-owned alternative to MetaMask. - https://epicenter.rocks/tallycashThis episode is hosted by Brian Fabian Crain. Show notes and listening options: epicenter.tv/431

Welcome to Ep Center, the show which talks about the technologies, process, and people driving decentralization and the blockchain revolution. I'm Brian Crane. Today, we're speaking with Elia and Alex. They're the co-founders of NIR Protocol. I've met these guys a long time ago in San Francisco, and they were just kind of starting out. And now since then, NIR has evolved into one of the leading smart contract ecosystems. they are, you know, kind of have also been among the leaders around sharding and creating a sharded proof of state blockchains. And, you know, it's become really vibrant, vibrant ecosystem with, like, lots of people building on it. So, super excited to, to dive into that. Now, before we go to that, with Eli and Alex, just a few words about our sponsors. So first of all, we have Talley. So Talley is a new

wallet for Web3 and DFI. And that sees the wallet as a block. public goods. So it's a bit like a community-owned Metamask alternative. There's all the features of Metamask, but it's fully open source. And it's 100% user-owned. So profits go into a community, not a corporation. So the launch of Talley is coming this year, but there's an early version, community edition that's out. And, you know, if you want to get involved, go join the Discord or check it out at tally.cash. And our second sponsor is Gnosis Safe. So the Gnosis Safe is a smart wallet that enables you to control digital asset with much more granular permissions.

So you can use multiple private keys, a subset of which, you know, to require for executing transactions. And then you can store the keys on different devices, hardware or software, and even share them among multiple people. So it's basically, Gnosis safe has the best, and personalization and customization among kind of Web 3 asset management or wallets. And so it's become really massive as a solution for individual schemes and dolls and storing over $100 billion worth of assets on there. And also, Gnosis Save is now live on Aurora, which we can touch on in this episode, which

is the EVM that's running on near network. So even new users can start using the Gnosis safe. So yeah, go check out the Gnosis safe. And with that, let's go to our episode. Thanks so much for joining me today. It's great to finally have you on. This has been like for a long time. It's like we've got to do a near episode.

We have to do a near episode. So like I'm happy it's finally happening. Yeah, thanks Brian for inviting us. Excited to be here. Okay. So let's let's start a little bit at the beginning. Tell us, like, how did you end up deciding to start building near and build a, you know, layer one smart contract platform?

Our origin story starts with us actually working on AI, hence near AI. The idea that AI is near and singularity is coming, which is a separate topic, we should probably have another episode on. But we were working on. kind of teaching machines to program. And to do that, we actually worked with a lot of people around the world to collect data. And kind of the data we needed was pretty specific. We wanted people to describe code to write code for problems we had,

which means we needed kind of a wide cast of people across the world who were able to do that. And mostly it was students of universities kind of in places like China, Russia, Ukraine, and kind of other countries. And we, being a U.S. company, just had trouble paying them. Like sending money to all those countries has some problem, plus not all the students actually have a bank account, or at least a bank account that can receive foreign transfers. And we started looking at blockchain as a kind of solution to the problem

we had ourselves, right? And kind of as we dive in, it obviously evolved into, well, how do we build a kind of crowdsourcing as a service platform on blockchain? And then kind of diving in, realizing the limitations of the kind of blockchain technologies, right? At that point, you know, Bitcoin and Ethereum obviously were the two main ones. There are a few others who already launched. But none of them would they be able to handle kind of micro transactions and, um, like level of usage that we would expect, right? At the cost, which is reasonable if you're paying...

15 cents. Yeah, we were paying like... Well, not 15 cents, but a couple bucks per person, so you need transaction fees which are adequate for the use case. So back then, it was not possible, right? So crypto was unusable for the use case, and here we see, well, this is a problem. That's a problem we have.

So if we have it, someone else probably does as well. right and then are we uniquely positioned to solve it we are pretty well positioned to solve it right i was building databases before ilia was working on tensor flow which is also pretty low level stuff and we happen to have plenty of people around us who were also with the databases background or systems background who were in between things right so they either just left their their work their job at google or also msicle where i'm from or facebook to look for something fun and cool or they were still working somewhere but they were extremely unhappy

constantly sharing this in happiness with us. So we were able to very quickly identify in our internal network how many like six other people around six people who were immediately available to join. So we grew from three people building AI to nine people building a blockchain

on a night from Sunday to Monday. And so that's how near started. I think you guys were part of Wight Combinator as well. So was that with the the AI, basically NIR AI, and then it evolved into this blockchain? Near is not a YC company.

YC company was a different one. So I started a company with another person. It was in reverse. We started a company for the sake of starting company, and then we're like, we'll figure out what to build. That's like exact opposite of the textbook approach. And as we were building it, we went to YC. That's when we met Ilya. So Ilya joined

us while we were in YC. And then at the end of the YC, there was certain founder. We did not quite agree on the future direction, right? So I, we separated and reincorporated into NIR. So Ily and I wanted to build program synthesis. The third co-founder did not like the idea of program synthesis. So NIR is not a YC company, but we all met sort of during that time, me and Ilya.

And you guys have been through like a long journey together. How has it been to work with each other as co-founders? It's a healthy relationship. Yeah, I mean, it's, you know, it's a, it's a journey of ups and down. Like any startup is journey of ups and downs, but it's good to have kind of a partner who you can, you know, work with and share with and know that you're able to kind of continuously push through any challenges. Yes, yes.

We've been through more downs than I've been in my marriage in years. I remember actually when I was speaking with you guys in, maybe it was 2018 or 2019, but at the time there was already this like EF2 roadmap and you know, this idea of this like Charlotte EF2. And I remember, I think even when we were speaking with you guys, you were basically saying, like, look, this is kind of like pretty much the same as EF2, you know, in terms of like the architecture. but, you know, we're just going to be better at executing it and, like, you know, we're going to do a better job of building it. I'm now, I think, now since then, a lot has changed, right? Like, I think NIA has probably developed a lot. Also, Ethereum has, you know, gone through many, you know, many iterations in their philosophy. I wonder, like, how has, how has, like, the nearer vision and the near idea, like, changed since the start?

it. I would say actually, so kind of when, you know, when we started, there were like one thing that was clear, right, is that, you know, if you want people to use the blockchain technology, which, you know, we wanted to, you need to make it kind of dirt cheap, which also, like, naturally means it should be scalable and ability to accept any user that comes to. And the only way to do that, right, is charting. And to be clear, at that point, we did not know about these two. We quickly learned about it.

We quickly learned. But, yeah, like, when we started, we were like, hey, sharding is needed. We looked at all the stuff. Like, we looked at DFINITY. We looked at kind of EOS and, like, all of the, you know, IOTA, all of the folks who were at that point kind of super hyped. Definity was not sharded yet. That was later.

Yeah. And so we're like, none of them are actually solving or planning to solve it, like, in the roadmap, planning to solve it. planning to solve the problems we're seeing in the way we see fit, right? And then we did go to like East San Francisco, I think, and learned more about well, there are different sharding designs in the existence. One of them Alex end up implementing at East San Francisco. But yeah, I think the kind of the realization was also pretty quickly is that

beyond just charting, beyond just kind of just scaling capability, it's about usability, right? And actually scalability becomes just a piece of it because as a user, I should not need to worry about that some Cryptoketes are running wild or, you know, somebody runs some trading bots and kind of willing to spend hundreds of thousands of dollars on fees. Like, I just want to use the stuff and have a predictable experience. And on the flip side, as a developer, I also just want to sit down and, you know, write some code, ship it, and get users really quickly. So I think kind of the way we now frame this is that, you know, the experience should be simple, secure, and scalable, right?

The blockchain should be as hidden as possible while delivering on the promise. The security should be there, right, to, you know, provide your economic security as well as actually fit back into the user space, you know, things like, you know, is this contract may rack pull you, you know, how to make sure that if seat phrases are accidentally leaked, this transaction will not pass, like all the security system that should be built kind of in middleware. And then, and like we've built some tools on the back end in a protocol to enable that. And then the scalability is, yes, it should scale to billions of users. Otherwise, like, this technology is not going to get adopted, right?

And we're going to end up in a black mirror episode. I also wanted to touch a little on what you mentioned about us believing in the past that we can execute better than Ethereum. Right. So when we were talking three years ago, like we didn't know anything of this. And we needed we needed something to say. But yeah, so what happened was that we started designing sharding. And if you when you start thinking, like if you read the papers from all the sharded blockchains, like the early papers, the first papers they've had, they're all very similar. Because once you start thinking, there's a particular direction you take. And so we all took that direction. We all like diverged a little bit, right? So Ethereum and us and both. codot, we all believed in a slightly higher level of security where you don't trust,

like small validator sets, which are sampled from a big set, like some other chains, did trust, etc. But there wasn't much differentiation at the beginning. But then what was on our side was that we were a group of people in a single room, right, with a whiteboard, while Ethereum was significantly more widespread decentralized system. and because of that we were able to quickly iterate and see what doesn't work. So what happened was that very early on we realized that that design that everybody comes up with is unusable. It's unusable.

It's super complex. Like it will take a very long time to build it. The interaction with the system would be pretty suboptimal. And so what happened was that early on we just went ahead and deleted the entire code base we've built in the first seven months. We just purged it and we started over with a secretive. significantly simpler design called nightshade. And eventually what happened was that Ethereum also realized that, like, the original design is too complex. But it took them significantly longer because they didn't have this insight, which we got very early by building it, by starting building it.

So the time was on our side because of this, because of us being in the same room with the whiteboard and moving quickly. Yeah, and I think maybe diving in into nightshade kind of how it kind of, how it kind of. compares, right? The basic idea is that instead of sharding blockchains, right, and having lots of blockchain running in parallel, and having all the problems of communication between them and keeping track of them, which is, you know, some of the chains who went this way are, kind of continuously need to solve for. We actually sharding blocks. And so it was in, in a way, like, you know, there's this meme of big blocks. And so, like, yes, at some point, you cannot, you know, increase the size of block because then between like executing it and transporting it,

it will take significant time. And so we actually splitting block into so-called chunks that we, that are processed in parallel, that are kind of collected in parallel. And that allows us to have kind of still one single chain, right? From a user perspective, from developer perspective, it's one blockchain. They don't need to know about kind of underlying sharding design layout or anything. and they are able to kind of communicate with blockchain as if it's a single entity, but we can actually paralyze processing, paralyzed storage, paralyzed kind of block collection

and propagation network. Yeah. So all of the pieces that are bottlenecks right now in blockchains are now paralyzed. And the most interesting thing, which is still in our future roadmap, is ability to dynamically kind of reallocate a kind of increased number of the charts, right? And so this way we can actually dynamically grow block size and state size based on the usage of the blockchain. As more users come in, we actually can increase capacity, which is a kind of precondition for the blockchains to be able to handle lots of users is ability to dynamically scale up, right? Like you never hear from Facebook.

It's like, oh, when you log in, it's like, wait, wait, guys, you know, there's already like, you know, 10 million users. you need to wait for a few minutes. It's like, no, it actually just built more data centers underneath. And so the eventual goal is to be able to do that in, you know, permissionless setting. That's great. Like I'm really excited to kind of dive into this. Like one thing that kind of, it reminds me of when you say, okay, like this, splitting the blocks into chunks and, you know, processing in parallel, right?

In Solana, they basically do something a little bit similar, right, where they're basically saying, like, okay, you know, what are the transactions that, like, don't touch each other in terms of state? And then they're using these GPUs to also, like, execute them in parallel. Now, they don't have, it's still on like a single, you know, single validator, single machine. You have to do something similar here, right? Because I guess you obviously can't have transactional contracts that, you know, affect each other in a single block, you know, split across different validators. So, like, how do you deal with the kind of interactions between different programs and

transactions? So Salana paralyzes processing, right? So that allows you to utilize, well, multiple cores or, like, in the future, they're talking on GPUs. There's no GPUs today, I guess. it also allows them to use the the fact that SSDs todays are very good at processing parallel requests

so you can read them right in parallel but they do not take advantage of like they don't paralyze network right every validator still needs to receive the full block with all the transactions not only every validator but also every node that is watching the network so that's a slightly bigger problem so it is it is maybe reasonable

to require validators to run very expensive hardware right like let's put this question aside, but it's building a system like that also requires every node in the system to run an expensive hardware, right? So that is actually damaging in the sense that it costs a lot of money if you just want to ensure that the network is operating correctly. Right. So in sharded system, what you do is you first split the state. So the state, the entire state, is split into multiple shards. And then as a node, you choose which charts you want to. So if you're not validating note you choose which shards you track.

Right. And so with a very cheap hardware, you can go and validate a single short. But as a community, like if the community has 10,000 nodes and like assuming that people choose which charts to validate somewhat evenly, you have the entire network being validated

by a very large number of people with cheap hardware. Validators are assigned shorts. So if you're validator, you're told which chart you're validating. And then you only have to download state and transactions and chunks only for that chart. So it significantly reduces, first of all, your requirements for the disk storage, right? The state explodes in blockchains today, but you only need to store one shard worth of state,

which is its full state divided by number of charts. It's significantly smaller. And the network requirement is also smaller because you only need to download transactions which are touching your state. That introduces its own challenges, specifically transactions do not like to only touch state of a single shard, it happens that transactions often do touch state of multiple charts. Even a transaction as simple as me sending money to Ilya, if we do happen to reside in different charts, it is a cross-shart transaction.

So it introduces this challenge. That on itself is a pretty interesting problem. We can talk about it separately. So it needs to be solved. But in comparison with the sort of monolith blockchains, which are paralyzing processing, they're solving for one bottleneck, which is storage. So CPU is not a bottleneck.

CPU is not a bottleneck for any blockchain today, but they are solving storage as a bottleneck, but not network. And when I mean storage, I mean like I.O. I.O. speed. So there are three bottlenecks. One is IOS speed. One is how much storage you can actually fit on a single machine, right? Like the state of the blockchain grows.

And the third one is network. So by paralyzing processing, you are solving for a yo speed, but you're not solving for network and you're not solving for the size of the state that you need to store. So would it be then, okay, let's say, something like a uniswap or some decks and then that's on like you know a particular chart and if i'm i for example i want to run a node i want to know uh what's going on on that decks then i just run the note for that chart and then moreover there's a particular feature which allows you to say hey i care about this account and that will automatically track whichever short that

account resides on right so it's even made very simple for you to have a node which tracks a particular set of accounts. Yeah, let's talk about the, I mean, is there some kind of cross-shart, like how do cross-shard interactions work? So, yeah, this is where the cost for the scalability comes from, right? There's no free lunch. And so the cost is that pretty much logically, every single contract on NIR is actually lives in its own logical shard.

So they all live kind of in parallel. And if you want to communicate between any of the contracts, the model is not kind of what Ethereum and any other monolith blockchins are using, but actually a sending message and receiving messages. That's kind of the communication protocol. And so this is actually way more similar to kind of services, like microservices architecture that exists in, you know, in regular fintech and in. in web where each service kind of lives independently has some piece of state associated to it and

they communicate with each other through messages and then the kind of the protocol underneath kind of groups this logical charts right logic like smart contracts into a physical chart and actual short and and facilitates the communication right so when one contract for example my account sends money to uniswap, right? I create a message saying, you know, send like NN near, for example, to this other uniswap contract, that protocol, you know, sees this message, routed it to the right chart, that chart receives it as in like just a message that coming in, similar to any other, in a way, transaction, just as some metadata attached, process that for the uniswap

contract, and then routes it, for example, it's some outgoing funds, for example, going into another account to the next thing. And so this, in a way, adds, I would say, some complexity compared to, for example, a theory model where everything is synchronous. And when you're calling another contract, you'll get back the result within the same transaction. And anything fails.

The whole thing kind of rolls back. Here, you kind of, you, if something failed in uniswap, then you will get a callback saying that that failed. But then you need to handle kind of what's that kind of result or failure need to be like the way it needs to be handled for your specific contract. And it takes a little bit of time, right, because the messaging is communicating between chunks, between chunks produced. And so it may take like one or two seconds if this is a complex multi-contract transaction. But in result, you know, that's why we have like one second blocks, which are, you know, propagate really quickly and allow us to route these messages really quickly.

And there is also interesting things like Aurora, which comes into offset some of this as well. So, so then this is the case like between any kind of small contract interactions that you basically don't have this, you know that you have this I guess it reminds me a little bit of sort of the Cosmos IBC model in a way yeah it is that's what I'm saying like in a way logically you can think that every contract on near

is its own chain it's on Cosmos zone yeah it's almost it's on Cosmos zone and we just have a really you know fast IBC that is under the same security assumptions and that and that's the main thing is actually security assumptions are exactly the same. And so as a contract developer, as a user, you don't need to think

about like, oh, is that the zone going to blow up? Is this messages are coming? Like, users don't need to think about that at all. And developers either. Like, they think of it as a model of the system that kind of runs all the services and communication between them. But

underneath, you know, because of this, we can actually rearrange where the contracts live physically. Right? We can actually move them between shards dynamically. And that's kind of like what's always been on our roadmap. We can, you know, if, for example, one of the contracts becomes really popular, we can actually move it out into its own shard.

And now it has way more capacity, right? It has full capacity of the full shard, which is, you know, as much as one computer can process. And importantly, if you were on the same shard, you're not affected anymore when it's moved out. So you don't suffer because someone deployed something very popular, which happened to be on the same chart as you. And by not suffer meaning, like, as well, the networking is not broken. Because right now, what we've seen so far, right, is every time some contract becomes popular, it's not even that the, like, you know, processing gets, I mean, obviously things get expensive.

It's a price auction, but the network gets flooded with the messages because, like, somebody runs bots or whatever. And so, again, the point is, like, you isolate it into separate networking. And so all the other processing continues kind of as it is. And so Aurora is a great example because it actually runs on a separate chart because it is a popular contract on NIR. You know, we can dive in like what does that actually mean. But kind of we already have this in a more, I would say, governance way where we can allocate kind of contracts and charts and split as a state more like through governance versus dynamically. But over time, the idea is to kind of have that, you know, reallocation dynamics similar how AWS, you know, can scale your like,

database or scale your websites with law and financing type of thing. Okay, that's very, very interesting, very cool. Yeah, I guess it also sort of like illustrates, I think what you guys are saying is no, like we use this term like sharding and blockchain and I get, this just seems to be a lot of differences in how it has actually understood and how it's implemented. Well, to be clear, it's the same in, in, regular systems programming.

There's a concept of sharding, which means like process stuff in parallel. And then how exactly you implement really depends on specific architecture of the database or, you know, services you're building. Yeah. Cassandra, Vulteby and single store are all sharded, but there's no similarities in their architectures. So, yeah, let's talk about it. Maybe it's sort of like the state of it right now. I think my understanding is there's four shards.

Is that correct? Yeah, there's four shots right now with one dedicated for Aurora. Okay, so maybe let's start with Aurora. So Aurora is basically like an EVM, EVM chart, right? Exactly, yeah. So this was kind of stepping back, right? We mentioned the developer experience, right? And so we were kind of optimizing for how do we make it really simple to build applications on NIR?

And that means, you know, using something that people are familiar with that is... People outside of crypto. Yeah, people outside of crypto. And things that you can pull in existing code. That was also important piece because, like, if I'm built, like, you know, most of the development usually is just pulling in, you know, five libraries and then stringing them together. And so we chose to use WebAssembly because it's because it gave us. kind of the, this platform that there's a lot, that's a huge community of people for building

compilers and kind of instrumentation and tooling for, right? Web assembly runs in every single browser, probably while we're recording this somewhere, you know, WebAssembly actually runs to render some of the graphics. And so that gave us kind of the fundamental pieces. And then this was kind of obviously a detour from how a lot of developers in crypto, or kind of back then we're thinking because they were all building a solidity for EDM. And kind of as an idea, we always wanted to see how we can bring, you know, the existing code and existing products to near. And so at some point there was a prototype where we just took part of Open Ethereum, right,

part of the client, of parity client back then, and ran it, like compiled it to WebAssembly and ran it, right? again, because the whole point was that we can take existing code and just execute it. And so we actually got AVM to run as a smart contract on NIR. And so that's on its own is super powerful, right? Like it means you can run, you know, potentially a pretty complex piece of software. You can run Postgres as a smart contract. So you can run Postgres and smart contract potentially on NIR.

And not that you should. But you could, yeah. But, but, and there would be one interesting thing coming in, in, like that we are able to run, which enables a lot of new use cases, but I'll not spoil it. But with EVM, what happened is it became clear that we can actually build a environment, right? Think of it as a, we call them containers now, where all the ADM contracts can live in one kind of near smart contract. container and they inside can be synchronous because they actually will live on the same shard and communicate with each other and have state available to them.

And so that kind of kicked off this idea of Aurora, which is, well, actually, we can offer this as kind of isolated container that people can just go directly deploy, build their apps and create a very compatible environment to existing experiences, both of developers and users. which is also completely transparent to them. So like as Aurora user, you don't need to understand any of that. For all you care, there's an EVM contract on NIR and your METAM mask gladly connects to it and all the tooling works. Right.

So underneath, it's just a smart contract compiled into WAS and which runs all the VM smart contracts. But users don't need to know about it. For users, NIR is just a fully functional VM chain, which is interoperable with all the non-evm contracts that NIR has. Yeah. And so this concept, by the way, can be extended, right? You can have, you know, a single container with other languages and other frameworks. Including WASM. Including VASM itself. Yeah. So you can actually create a VASM from a contract that are synchronous with each other and call it, they can call each other synchronously on one of the charts, right? And so in a way, this is actually back in the day, Ethereum research was published about execution environments. And this is kind of, I mean, like similar to that idea, but actually like the specific implementation that also, you know, hooks in with all the tooling.

Cool. Interesting. I mean, it also seems similar in some ways to sort of the polka dot parachain model. I mean, to lesser extent, because polka dot and rollups on the Ethereum, right, the way they operate is by having a separate operator that kind of collects transactions, does. you know, ordering execution state, kind of state maintenance. And then they use the beacon chain or Ethereum main net as a way to settle and secure the state, right? And so what this means is you need to run separate validators or operators.

Collators, yeah. You need to run, you know, now you are responsible for, like whoever runs that responsible for censorship resistance, right? which like let's say in roll-up cases there's like you know one operator usually which there's so many ways this can go wrong and then and then you have kind of this like checking in state of your state you need to you know beacon chain to accept it to validate it you know and so that on top of it creates a complexity because now as a user and developer you're like oh my application is on this par chain or in this roll-up, my money are on this other roll-up, and I need to first, you know, transfer things to figure out, like, how to move, is it removable? How long do I need to wait for

the settlement? All those things, like just adding lots of complexity. With Aurora, there's no complexity because literally it's a smart contract. You can think, you know, from a different side, it's like a Y-Earn, you know, Walt, where, you know, you put money, for example, and it deploys it into some other things and it's in the same transaction, it's in the same network, right? There's no separate validators there's no separate kind of security assumptions or anything.

So wait, what if I want to run my own substrate chain? What if it is my use case? You can. How do I do that? With Near? Yeah. Well, we have Octopus Network for that. I saw that this Octavis firm was like, this is

like interesting, no? Because it sounded like some, okay, using near and then substrate chains and then IBC so it was like sort of so the way the way being user friendly means is it's not you know Ilya or Alex or you know somebody on our team decided that this is a user friendly part it's actually hearing what developers want and then making sure it's easy for them to do and so Aurora is example of like I really don't think people should write in solidity but people want to write solidity there's a lot of market for that and so Enabling them to do that on near was, you know, part of the part of this thing.

Similarly, and there are very specific cases when you do want to run a separate chain because, you know, you need to customize how the communication happens or you need to customize, like, very deeply, you know, some kind of state formation or zero knowledge integration or. Or you don't want to show your state. You don't want to show your state. You don't, you maybe want to remove fees completely. Like, and you have a different way to do resilience. and spam protection. And so all these ways, right, again, enabling them to do that in an easy way, right?

And so Octopus built by this folks in kind of, I mean, globally, but originally team from China, they kind of came up with this design where you can have a kind of smart contract on near main net, right, that facilitates all this and provides you leasing of security from near, right? So, and, and you can get pretty much validator, like collators who will run your chain when you, like, you're checking your web assembly of your chain now, not a smart contract, and, and this validators will kind of get picked and start running it. And then there's obviously some sets of, you know, security assumptions around that

to kind of facilitate it. But that'll, like, kind of octopus, the main benefit that is reasonably cheap to start this, and you can run, you know, tens of thousands of them because it's just as simple as kind of, from perspective of doing it, right, it's as simple as just deploying a web assembly as well and kind of, you know, creating some token economics around validators running it.

And it's substrate, right? And it's substrate, yeah. And I think they also want to extend it to Cosmosis decay, but right now it's a substrate. Yeah, that's cool. That's an interesting, yeah. Then now, maybe another question on the Aurora thing. So, like, now let's say we have Aurora and then,

you know, people writing smart contracts in there. If they want to, like, interact or in some way with, you know, let's say other smart contracts are written in WebAssembly on, like, different chart, how does that work? Do you need some kind of bridge for that? Or, like, how can they interoperate? Yeah. So there's a one missing piece right now on the roadmap. So to be clear, like a WebAssembly contract.

let's say, you know, some kind of AMM or whatever that wants to call into Aurora already does that. And there's actually examples of, you know, contracts on near that interact with contracts inside Aurora. And because for them, this is just a message, you know, through the regular API, just call Aurora contract with some arguments. And get the results. And get the results, yeah.

And then get call back pretty much after it's finished. The way back, it requires adding a new pre-compile to EBM, to Aurora EVM, that allows the contracts to pretty much call back, like call out of the Aurora and receive the callbacks later. And so that part is on roadmap. This hasn't been kind of yet prioritized, but it's there. And it's not that complex to add that. But right now, the folks who want to do this, do it the other way. So if you, for example, want to call something from EVM to some other of assembly contract, you just, you know, you do it the other way. You pull the data from the ADM kind of out.

But moving assets works. But if you need to move assets between Aurora and NIR, that is, it is not a bridge per se. Bridge usually assumes like bridging something with different levels of security. But Aurora is just depositing money into Aurora contract. That's what really happens. So it takes one second. It only relies on the security of NIR, nothing else.

So, you know, moving assets between Aurora and years. That's what I'm saying. Aurora is more of a, like, a vault that has, you know, different strategies in it, like, mentally for people than a roll-up. Because roll-ups assume different security, some different civil resistance and censorship resistance. And here you have, like, a vault that is a smart contract that you can deposit an investor funds. And then inside it, you can do different stuff with this kind of, like, similarly, we have actually ref finance, for example. our exchange as well where you can deposit funds and then you can trade without withdrawing them. Like it's not like un-swap, you know, you move funds and then you get them back or

your account. Here actually deposit funds, trade and then withdraw later. And so like this kind of pattern is pretty popular near because it allows you to kind of move in everything and then transact with something that doesn't require multiple kind of hops across smart contracts. And then the other shards, so, you know, we have Aurora Shard, the other three Shards, are they, they're just WebAssembly Shards? Well, they're all WebAssembly Shards. It's more of a, like, it's an Aurora contract is pinned to one of the shards, and then the other ones are just, all the other things are split, kind of evenly.

If you deploy a Wasam Contract today, you will be assigned randomly to one of the shards. And there is no benefit of being collocated with someone. So there's no reason for you to grind and try to get on the shard with someone else. You're not getting any benefit for that. Okay, so that latency, if I like want to interact with the decks and I end up being on the same shard, I still have the same kind of. Yeah, still one block latency for the message. Yeah. Which also has a lot of interesting front-run prevention things.

the more shards we have, the less predictable it is actually what other things will come from other charts. And so, like, even if you see a transaction coming and you try to front run it, first of all, like, there are probably some other stuff from other shards will come in, may come in before you. So as network grows, it actually becomes, like, more and more, like, interconnected and hard.

Unpredictable. Yeah, unpredictable to do things like front running. really i mean more complex maybe right but seems like very possible yeah this is not a solution this is just a it's like it makes it harder yeah it makes it harder and because like blocks are one second it's like you need to observe the whole network at all times pretty much and be probably a validator of a large like a large percentage of stake that's probably the only way to be like effectively effective at front running everybody else are not able to do that pretty much Like that's kind of way.

I mean, like, you can still, you know, do backgrounds, and that's what, you know, all the arbitrage spots are doing. But if we're talking about actual front running, like plug it in in front of your transaction, you need to be kind of a validator and you need to be like in all the charts, ideally to be able to observe it. So, I mean, we have four charts now. I mean, what's the limit here? Like, how, how, how,

far, like what are kind of the scalability limits to this? Right. So this takes us to this land of security assumptions, right? When you design sharding, what happens is that naturally because every validator only validates a subset of shorts, then every shard gets fewer validators than the security of the whole system, right? And so here you can make one of the two security assumptions. Security absorption number one says, hey, if I get a very large set of validators,

validators, like, let's say, 10,000, and a sample from them randomly, a thousand of validators. Then you can say, hey, if the original set had, let's say, no more than 30% of bad guys, then you can do some math, and you can deduce that the sample will also have, like, no more than 40% with probability 1 minus 1 over, you know, quadrillion, quadrillion, quagliant, something like that. So then you say, well, if I assume for my BFT consensus already that the whole set has no more than 30% I can assume that the sample will be safe right and so there are many sharder systems which are live today which rely on this assumption the problem so if we were relying on this assumption there would be nothing blocking us today from from going to significantly more shards however this assumption

has a problem which is you don't need to be bad guy in advance you can become a bad guy after you were assigned to a shard right so the idea here being that most of the validators they're not honest people they're reasonable people. They're optimizing for the upside. Right. And so if you do need to corrupt the chart, if you do need to do something bad in the chart, then you will wait until the validators are assigned.

And then you will go, you will identify them. There are fewer of them than the whole set. And you will corrupt them retroactively. Like you will bribe them or some... I can hack into their machines. Yeah. Well, if you can hack and you can probably hack them to everybody.

I mean, I guess you could, I don't know if you could have some... I mean, I guess the only way I could imagine some kind of scenario you're like that being plausible, right? It might be if you're, if you, if you basically do it via a smart contract, right, so that you could do put up like a bounty. Yes. Because like identifying, contracting, hacking into. Yes.

Yes. Yeah. Like I think two years ago, I wrote exactly a blog post which just describes like how the smart contract would look. The problem here is that in practice, those block producers, they're not like, they sit in the same groups, you know, they're in the same telegram. groups where they discuss like the problems they're facing or like the hardware requirements, etc. So it's very easy to find them. Right. So frequently it's also very easy to like find

the mapping between people and pools. Also because pools, many pools validate multiple networks. You also kind of know them from others. So it's easy to find them. It's definitely possible to like it doesn't have to be very possible to corrupt them. It's enough for it to be generally plausible for you not to want to build a blockchain which can be broken. working this way. Right? There are many things which look in practical, but when enough money is involved, they become doable. Right. So this concept is called adaptive corruption when you corrupt someone after the fact. And there are multiple protocols. So the one I know is polka. us and Ethereum 2 with their designs. They're designed with an assumption that

the chart can be adaptively corrupted. It's like a very large percentage, up to 100% of all the validator nodes can be corrupted. And then, And usually the assumption is that there's at least someone in the network who validates the short who is not corrupted. Right. So if you read the nitrate paper that we have for NIR, we even try to build it. Like we have some ideas how to address the situation where nobody voluntarily validates every short. But that becomes like pretty unreasonable. You usually expect that in the entire network is at least someone who is validating the short.

Like if nobody else, the exchanges do. Right. Indexers, exchanges. Indexes, yes, RPC notes. So then you need, what you do usually is you say, you do what optimistic roll-ups do. You say, hey, if something happened, like if you track a shard and you see that the validators did something stupid,

go and show it to us. So the entire system is built in such a way that any misbehavior can be proven cryptographically with a relatively small proof. And so if anyone observes something wrong, they can immediately send the proof to the network, the network will receive it, punish people who are to be punished, roll back. Right.

And so here the idea is that if you track all the shorts, you will know in advance something bad is happening. You shut down your operation. Right. So like if you're hypothetical exchange, you will track all the charts, right? You have resources for that. You don't need to rely on challenges because you know that something went wrong. You're actually probably going to be the entity sending the challenge.

If you do not have capacity to track all the charts, which majority of people will not, you only track a subset, but also you're the way. way you interact with the network changes, right? If you have a transaction which which transfers a lot of value, right, for which it is absolutely crucial for you that it is not rolled back, then you wait. You wait a little more to make sure the challenges are not coming in. For small transactions, you don't care. Like probably nobody will be rolling back the network because you bought like a $5.00 and that is the simple part. The hard part is that for you to send the challenge, you actually need to see the block. Like if the shard was corrupted and they get something

stupid. Because the shard was corrupted, they, like a very simple way to think about it is because we build sharded system with the understanding that nobody can download all the blocks, or at least majority of people cannot. Right. So that means that you should be able to validate or like operate the network, like interact with other charts by not seeing the full blocks, the full chunks in our case of that chart. Right. So you, like, you're acting like many, many parts of the system act as light clients. Right. I only see the head. and the signatures of the block producers and they act upon it.

So now if we are bad guys and we want to do something bad, we will send enough information to everybody for them to act on our bad behavior, but we will not release more than that. We will not release the full block of the full chunk. And so even though there's someone who's tracking the shard, they will not be able to download this data because we never published it in order to challenge us.

So that is one of the hardest problems in designing both shardusts system and roll-ups. like if you read research on roll-ups, you will see that data availability is always the biggest problem they're trying to solve. And the limitations they have today, like why optimism or Arbitrum run 200 or how many they run transactions per second

is not because of the execution or storage or network is because of data availability. And so one of the biggest bottlenecks and the biggest components of NEAR is the data availability subcomponent. And so that's one of the biggest bottlenecks we're solving. to extend to more charts, but also challenges.

They are not, challenges are not in the production state yet. So the network that operates today does not have challenges enabled. And so because of that, validator nodes actually do track all the charts. It's called phase zero of nightshade. So that's the second bottleneck, right? So before we scale, so we can probably go to more than four, we can probably go to eight, maybe even more, with this mode. But to scale to more, like to scale to 100 charts, we will need, obviously, both.

we will need challenges enabled. But challenges are the easier part. Data availability is the harder data availability is there. Data availability was the first thing we've built. Yeah, which is one of the issues with challenges is that because they don't actually happen in real life, right? So, like, normally, you know, if you're running a test net, you're testing all the behaviors, you know,

you're executing transactions, you're running blocks, you're distributing data availability. And so you, you know, you find all the issues right away. And with challenges, we actually have them, It never happened. They're not tested very well. And so we actually need to create an adversarial environments where people are maliciously

corrupting network to test all that properly. And so given there's an exploding ecosystem, there's a bunch of other things we are working on to solve for actually developers and users before kind of switching back to finalizing challenges and having that more like a probably another incentivized network where people are incentivized to actually be slashed. We're also probably nowhere close to the capacity today.

So you need to solve problems as they come. We are very, like we are very much facing a problem today that for people that's very hard to interact with blockchains. Right. So there's way more resources we're spending on usability and devalienable. capacity. It's very clear how to scale, but we know we're close to hitting it yet. Yeah. I think we did resharding. So part of this whole point that developers and users don't need to think about the shards is that we can change number of shards, as I said,

with governance. And so we did kind of late last year in November change from one shard, which we've been running from launch to four shards. And that was, you know, actually just like, I mean, there was a resharding mechanism that was happening for half a day underneath, right? But there was zero changes to users or developers, like how things interacting. No tooling needed to be changed. No, nothing. Zero down time. Yeah, zero downtime that was there.

And so kind of the idea is like to continue doing that pretty much ahead of any, you know, capacity grows that, at least right now with governance, we can continue adding more charts while also like adding some, you know, obviously testing more. for the important pieces and launching down. And so that's kind of being, you know, like a big piece of our philosophy, right, has been pragmatic and also continue, you know, continue innovating, continue trading to enable those things ahead of what users and developers want and need. Well, let's talk a bit about maybe usability and developer experience.

I remember that was always one. one of the things from the start that you were emphasizing a lot. I also remember you guys had this plan. I don't know if he ended up doing it, but to like focus on like high school students to get them like sort of get them early and get them all to near. Well, we have, actually I have this photo from my high school. And when I asked who has near, not just familiar with near who has near,

it was like out of, I don't know, 40 kids, I think like 35. So there's a bit of bias here. There's a bit of bias because it's my school. How did that happen? We run competitions. We run competition, like programming competitions. And so we sponsor that from near, and pretty much prizes are near for the kids. But the program competition is not near specific, right?

Yeah, it's like generic. It's like core forces. I mean, this is like the thing we've been training with we kind of running those, like sponsoring those competitions across, well, Mostly Ukraine right now. We did sponsor the biggest one in the end of the year on Code Forces. There was like 50,000 people there. Yeah. So we definitely kind of working in that, maybe not as globally as yet.

But we actually have a lot of global initiatives around the world, kind of targeting both students and professionals. Usability? Usability, yes. Yeah, usability, yeah. So what are, yeah, what do you think are the most important, you know, things that other blockchains do wrong and, you know, what are the most important differences of NIR in terms of usability?

So there are several things which we've done from very early, one from like the very first versions of NIR that, like, effectively it's very easy to find the problems. You just observe people interacting with the blockchain and you see the problems right away, right? And so there's a couple things that we've done from the very early on which are different. So one of the biggest ones is the account model. On

most of the blockchains today, your account is your public key. It has multiple problems. One of them is that it's very cryptic. You come to a person outside of crypto and say, hey, this is your account, this looks scary. The second problem is that your account is

attached to your private key. Like, that is a problem. Right? If your private key is compromised, well your account is gone right and at the very best you can what you can do now is you can transfer assets while you still have access to it right but well it assumes that assets are transferable right which is not the case in many cases it also assumes that you don't have some other value in your account so in near account and the keys are completely separate so your account it's a name it's like alex.near that's my account right and the the account can have essence

many keys as you want, and those keys have different permissions, right? So you can have a full access key, which is, which means this key can do whatever to the account, right? You can, you can add new keys, you can delete keys, you can invoke any contract, transfer, any money, right? Or you can have an access key which says, hey, this access key can only interact with a particular contract with a particular end point of the contract and has this spending allowance, right? And so now, if you have an account, like if I have my account, my private key with the full access, I have like somewhere in custody long hidden, right? But now if I want to, let's consider this sort of use case

where you have an account that has a lot of money. It also participates in some DAOS and also occasionally you play some NFT games or whatnot. So now for the full access, you wanted to be deep in the bunker in Nebraska, which nobody knows where. it is. Right. But now if I want to, if I want to go and vote in the DAO, I don't want every time to go. Now they know it's in Nebraska. Well, maybe I changed the state. Anyway, you don't want to go to Nebraska every time you want to vote on the DAO, right? So you want the key to, so now you can have another key specifically with the permission to the DAO,

but also you do not want to treat that key lightly, right? Like participation in DAO is a responsible thing. So that key, well, that key I will store in the ledger. So it is a ledger device next to me. I don't trust ledger, let's say, for my full money, right? I don't want someone to come to my place with, like, a range and get my password to the ledger. But I'm a key trusting ledger with participation in Dow. Now, if I'm playing a game, I don't want to use, like, ledger to sign every transaction, every action. So then I have another key, which is, hey, this key has access to the game. The key is stored in the local storage of the browser. So with the game, I interact as if it was a Web 2 game, right? Given that on near the block time is

two seconds, right? It's not real time. It's not counterstrike. But for a very wide variety of games, two seconds, latency is very acceptable. So now if your private keys in the local storage of the browser, then it's extremely playable. It's extremely usable, right? All the while, you still have the same account. So on Ethereum, you would, or like on many other blockchains, you will literally have to have multiple accounts, right? So for the game, maybe that's acceptable. Maybe I don't care which account to play the game from. But for the Dow, if it's not my main account now there's some social protocol where I need to say hey guys you know this is you know this account is me but I don't want to use it for the Dow so hey trust me that this account is

me I posted it on Twitter right well usually it's like it cannot go wrong it's a private chat on telegram where you send another key to people and then you also need to deposit more like money to pay fees on that account so and yeah yeah so so this account model is is nice it also has this very nice property on top of that, which is when you onboard new people, right? So you want to bring a person to the ecosystem. You don't want them to understand what ledger is. You don't want them to understand the sort of the hygiene of properly maintaining private keys. It's a pretty complex topic. So what you can do instead is instead you can have a centralized gate, which stores the private key in its own database, right? Which can walk away and like pull the rug

at any moment. But you use the centralized gate to onboard people to interact with like small transactions. You say, hey, come to near, buy the the NFTs here, like, you know, play with this ecosystem projects with like a small amount of money just to get a fill of it, the key could be in a centralized database of a centralized gateway, which is extremely usable. Now you play with near and eventually you buy an NFT, NFT goes in price. Now you have $10,000 NFT on your account. You kind of don't want to trust the gateway anymore. Well, nothing can be easier. You just trust them one last time to change your key to the key you have on ledger. Now you actually have an incentive to understand how to properly,

organize your private keys, where to store them, how not to lose them, right? Because you have this NFT that you don't want to lose. Right. And so you swap the key. It's the same account you've been using all this time, but now it has full security. Right. So it's very hard to do with any different account model. And it's easy to turn kind of your account into a multi-sick because you just add multiple keys that then are required to sign on something to, for example, for an operation or set of operations. you can create like a deadline switch on doubles account again not changing anything to say so like it's pretty much it's experience that you can build on top right that kind of is very malleable and

allows you to kind of continue programming on and so developers then can build new experiences so one of the coolest things we've had from like from pretty already on is that you can send somebody a link and that link actually contains a private key. And so that private key is just to sign one transaction ever that will create account and move money to your account. So there's a contract on NIR that hosts kind of tons of public keys to which if you have a private key, you can send one transaction and then it will look up how much money that public key was deposited

and give you this money and delete that public key from being active again. And so by doing this, like it's called link drop, right? You can actually onboard people, and we've been doing this as scare codes and there's links and there's everything. You can just send people, you know, money, NFTs, whatever. Like, you can send them in Dow participation. Like, you can send them like a link that is a private key that signs one transaction that is joined as Dow. Right. And so now they create account.

They have a little bit of money, you know, for fees. And then they're a member of a Dow from that. So you can program whatever complex, you know, experience you want. kind of and this is just like sending them a link via you know text message or telegram and obviously you can scale that up then like how do you bring a bunch of users through that as well you can also sell pre-configured accounts yeah there's a there's a marketplace on here where you can sell accounts like your account has some a collection of NFTs which is unique and you sell it well even more interesting you can be the author of a bunch of NFTs that you sold but

you're receiving royalties so one of the things that near has as this more kind of sophisticated NFT standard because it was designed by all the NFT marketplaces on NIR. And so they embedded royalties into the standard, which means that, like, as I create a bunch of NFTs, I sold them, this NFTs have encoded that I'm the author and they receive a small fee when they get resold through all the marketplaces. And by I, I mean this account.

And so this account becomes in a way of business that has a revenue stream from a future sales, those NFTs, and you can sell this business or turn it into a Dow pretty much from that spot, right? And again, this is like, in Ethereum, you would need to like create a bunch of accounts, you know, deploy contracts, do all this stuff ahead of time. And if you already done this, you will not be able to change that. Like on NIR, this allows you to kind of really easily kind of, you know, turn it into a Dow, issue a token, you know, now people can receive this revenue stream from this token, for example. Or you can go and sell it as a business, like as a quote-a-code

business on one of the account marketplaces. Right, right. I mean, a lot of from what you were describing actually sounds a lot like, you know, something that Gnosis safe does on, on Ethereum, right? It's basically this like smart contract wallet that, you know, but of course here, the nice thing being that it being like, you know, natively like a native thing, right? and including integrated, I guess, with something that's a lot like ENS, right? And you're, okay, Alex dot near.

And with just, I guess, a lot less friction than you have with something like Yeah, we looked at real use cases and we looked at kind of, you know, things like the ACL, like normal account management in, you know, in Web 2 and then kind of brought it all together into one model that then people can build on top. Yeah, we have, we have couple applications today on NIR which are not targeting crypto audience. They're targeting normal people. Well, non-crypto, I guess. And very infrequently do we see people complaining about something going wrong, right?

So we have like a mechanical torque, if you know what it is. So that's what it started with, right? I wanted to label data. We couldn't. We built NIR. So there is a labeling platform now on NIR. So the actual use case was solved. And people who work on labeling platforms,

that's people from all over the world who need money, right? And they come and work, but they're not crypto-native. And usually they generally are very non-tax-saving, right? They do not, like, for many of them, like Instagram and Internet, as synonyms, right? There's like factory workers, people who work in the service industry. Or people who just do not work because of pandemic, right? So they come and work on this portal.

very rarely do we see the support channels people complaining that something goes wrong. People do those accounts still, right? So the hygiene of maintaining private case is still a little complex, but that like we solve through education and through better tooling. So we improve. The thing is that our infrastructure allows to improve on that. But they don't understand how to create an account. They don't understand how to use it to interact with an application.

They don't understand how to ultimately move money. out and cash them to do whatever they need on the daily life. And they sell accounts. And yes, they do sell accounts. So the idea was that the portal was launched. Eventually the amount of, it became extremely popular because people do want to earn money. And so unfortunately, the demand. The demand, what would be supply?

What would demand here? I guess supply is workers, right? Yeah. No, demand is workers. Anyway, there was way more workers than work. Right. And so the portal shut down the invites. And so now any account that has an invite is suddenly a very valuable thing.

So those accounts are being sold constantly for quite a bit of money. Right. And if accounts were not sellable, well, then you would have a dead weight if you could work anymore. Yeah. How do you have privacy, right? So you have like, okay, Alex. dot near and then, I mean, I guess all of the address,

or accounts associated with that, of course, would be like link invisible or, like, would you imagine that people then have some sort of anonymous dot near, I don't know, and then they keep like Alex dot near and you have like, I don't know, dark Alex. Or like how? You don't even have to have a dot near account. You can have an account which is a public key. Though ironically, the public key account is still like a full-fledged near account, so you can change the private key later.

it's still going to be a public key account, but it will have nothing to do with the corresponding private key. But you can have any obscure name if you want to. Answering the second part of the question, which is implied, I guess, there are, I don't know if anyone is live, but there are multiple teams working on,

like, tornadoes, caches of the world. Yeah. Generally, like, blockchain right now is a, it's not a privacy engine. It's a transparency engine, right? And so, in a way, like, it creates transparency, and that's how we have, you know, Dows and kind of, consensus and but at the same time there needs to be privacy and so privacy is built kind of

on top and so yeah the the goal for sure is to be able to have like a private transactions even if they're executed as smart contracts and that's the whole point that you can run you know another chain worse of logic as a smart contract linear um that your account direct with and so yes you know turn out of cash zcash style uh things can and run on NEAR kind of a smart contract allowing you to transact privately as well. And the interesting thing, again, is that, so Aurora is kind of doing that right now. And so they tweaked it a little bit, but they, for a long time, they were running with zero fees. Right.

So they actually hit the fee for paying for the blockchain from the user and then covered the kind of the fee that blockchain requires like in NIR themselves. and then kind of created an economic model around that. And the kind of the logic there among other things were, first of all, it's way more usable if you do that. And you can actually charge, you know, flat fee like $5, for example, for the service or like you can do all kinds of things on top. And like specifically this is this gateway, right? You don't even trusting it because you're actually signing with your key

and the gateway just propagates and pays a fees. And so when we're talking about privacy, kind of, the goal will be to also have similar model where you're not actually propagating a transaction directly from your account, you'll start propagating it through some of the three layers. And you just kind of pay some substitution fee to them such that now you're able to transact in just like privacy pools without revealing who you are and then still be able to like visibly vote on Tao's and maybe, you know, buy your NFTs and showcase them to everyone. as long as you have the primitives for BLS signatures,

none of that needs to be on the protocol level. So any other systems which rely on zero knowledge proofs or any similar technologies, they can just be built as a contract. Cool. Well, let's talk a little bit about maybe like ecosystem and, you know, what's going on in the near, yeah, the near world. one thing was mentioned

I think one of your team was also like sent a reference to that is this thing called Pagoda I don't know Ilya can you talk about that what is pagoda? For sure yeah so kind of the I would say again starting a little bit from philosophy

right so I worked at Google and Google is a very kind of interesting place when you get in because inside they kind of build this like open source culture where all the source code for all the products is open in one repository. You have all the services that you can latch on and hook in, I mean, with some PII, et cetera, permissions, obviously. And you can also contribute and maybe participate in other projects,

and you can start your new project. But it's a permission model at the end. And importantly, it also doesn't have internal kind of way to decide which projects are more valuable than others, right? it's pretty much like some VP deciding at the end if we should shut down this project or start a new one. And so kind of philosophically, what we're trying to build this new ecosystem

is a I called Open Google, right? It's this idea that you have a common platform, right, which everybody builds on, latches on that is decentralized. And then everybody can have a kind of their own project team, you know, thing which work together. They still are kind of one ecosystem that is collaborating and working together, but they all have their independent kind of economic models, right? And so Aurora is a great example because it was actually, you know, part of our team that was

working with us that came out as a separate entity, as a separate organization. They had their own fundraise. They launched their own token. They kind of operating and growing right now as themselves. And that on its own, on its own, creates. it's like a huge scale because Aurora itself is actually like a huge ecosystem now

that has whatever like probably like few projects launching every week now like you know NOSIS launched and AesR scan launched and all kind of stuff and so similarly we have the other projects of you know similar scale like Octopus is obviously another one which has a big ecosystem itself as kind of

independent team we have a Makina which is like a storage project we have Kalimera, which is a more enterprise private chart as well. And so kind of as this has been happening, like all of this project still exists and work on the same core, right, on the same protocol, kind of either by using it, by building to it, by contributing to it, by, you know, pulling people to have had more stuff. And so that's kind of the idea that like the ecosystem is continued, you know, growing.

There's more participants. Everybody's contributing. And so for people from now is open source, this is very similar to something Linux, where you have a Linux project, which is kind of the kernel and a lot of like tooling around it, which is an open source project that kind of runs independently of any company or foundation. It exists. It existed and probably kind of continue to exist. And there's Linux foundation, which is designed to kind of propagate and, you know, protect the brand and, you know, pull people and create marketing and do all the stuff. And then there is companies like Red Hat, canonical, you know, Linux. like Intel and Google and Microsoft, who all have teams working on these protocols.

But then they have business around it that they offer kind of to their clients, right? Or they run it, like Asia runs, you know, tons of Linux, so they want to contribute to it. So similarly, you know, we have all these teams now who are doing this. And so our original company, right, the company that is all started with, in the way it's transforming, right? It's transforming to this new thing, which is pagoda. and pagoda is a Web3 startup platform.

It's a place where you can come in and you get all the tooling you need to develop your startup, right? This is, you know, all the RPC data, all the indexing, all the, you know, with like token launch toolkits and, you know, you have wallet kind of APIs and all the stuff.

And it's, this is the biggest contributor to all the open source, like of near protocol, of SDKs of APIs, which is all the open source projects, but there are other contributors as well. And so kind of this creates like an alignment because there's a business model and there's kind of a clear, you know, desire to improve for the customers that are using this platform while still continue contributing to this kind of open source project that everybody runs. And then on parallel, I mean, I would say like on a flip side, you have a ton of stuff that specifically designed to do go to market, right? And so the foundation is in a way this, you know, I would say like a kind of initial booster of the ecosystem, but it's, you know, it's actually. not about foundation. It's about now things like proximity labs, which is helping a lot of

defy projects to be successful to kind of launch to build. There's things like human guilt, which works with I think like 100 founders, but like 30 games building there, like tons of NFT marketplace, an NFT project, like a ton of people who are kind of, they have a huge community. We have things like Metababab, which is EcoFund. We have things kind of in Ukraine, which is binary star that are, you know, hosting and developing a bunch of projects. So in a way, it's kind of, you know, ever-extended ecosystem with a lot of participants who are working together, who are coordinating, and at the same time having their own kind of incentives and business models around that.

And there's a diagram somewhere that we can probably link kind of in a pretty way, putting it all together. Yeah. Yeah, near it needed to exist for us to launch, but... now just one of the many participants. And so there for you, Brendan. So for you, for you guys, what are the biggest, you know,

the biggest things that you feel like, okay, you know, these are, you know, some really hard problems or like the biggest challenges that are still ahead? Yeah, so I mentioned kind of the security, simplicity, security and scalability, and we made pretty good progress in simplicity and scalability, but security is still a big,

concern for everyone in blockchain. And if we want to get to a billion users, which is our kind of nearest, you know, outstanding, like, big, hairy goal is we need to solve that. And so kind of one of the, one of the efforts of being there is contract registry. So how do we keep track of, you know, contracts, their source code, their audits, and potentially security advisories, right, which are indicating that there's something wrong with this contract. and so people should be cautious, right? So this way, when you're in your wallet, right, transacting with this contract,

it actually can surface this information directly and being able to provide you the kind of heads up if something is happening. We can also do active, you know, thread detection and prevention directly in wallets and kind of wallet services, pretty much realizing that, you know, some NPM packages were maliciously attacked.

Some, you know, some types of accounts and contracts are being compromised, right? You're transacting with someone. like things like AML and can be done within this framework. And beyond that, you know, we're talking about, you know, seat phrases. Sit phrases are really easy to lose. And this is like already in Web 2, you know, we have passwords and,

you know, P passwords been leaking all the time and obviously like this, its own set of problems why this is happening. But we have to build a lot of tooling to figure out how to detect when this is not you actually going into it, right? And so we can actually build, I call it active custody, where there's someone else who is analyzing, like you sign this transaction, right? And it analyzes if this is you sign the transaction. Is there some, again, NPM packages, you know, getting hacked, seed phrases, getting, you know, stolen,

like can we detect that? Can we analyze that you're signing, you know, halfway around the world? Can we detect that this is a very suspicious type of transaction and then have a co-signer that analyzes that? that analyzes that and decides if they want to sign or not. And co-signers can be, you know, your friends, for example, kind of, you know, your friend's computer, maybe a bank or some kind of other custodian,

or potentially validated themselves on the network, right, who already actually securing its network. And so this kind of like expanding really beyond, you know, seed phrase is like the only way that, like, if somebody gets your seat phrase, I mean, obviously we've done some of it with just kind of permission control, but even beyond that, how do we, how do we create more security around that?

I think beyond that is education. So I think biggest problem is still people don't not know how the staff works and they're scared. They're scared because of security partially and like they see, you know, wreck pools and money stolen and broken and all the things. Like developers are scared to launch staff. Developers are scared to build things and go into blockchain as well.

And users are scared to use these because don't fully understand what's going on. And like on one side, we should make it easier so they don't need to understand, but on the other side, we need to educate, we need to bring more people in. And so we've been running near university, but really kind of scaling that up, right? So right now we, you know, thought like 5,000 people, but, you know, how do we go to a million people from there, kind of across the world, kind of educating and bringing people up into this ecosystem?

Well, thanks so much, guys. It's been really great to, you know, hear about Near, hear about, like, the progress. It's also been great from, like, sort of us with course, one, be able to, like, you know, run nodes, participate in the progress of the network. And, yeah, I think it's really exciting. I think it's come a long way and I'm super excited to see, you know, what the next years and decades hold for NIR and to see whether you can make it to the, you know, one billion users and beyond.

Exactly. Just the beginning. Well, thanks so much, and thanks so much for listeners as well. And we'll see you next week. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud,

or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us,

guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.