ZK VERIFIABLE APPS with Butian Li of Blockless

4 Aug 2023 · 58:48

Sebastien Couture interviews Butian Li of Blockless for The Interop, a conversation centered on zero-knowledge verifiable applications within the interchain ecosystem. Running close to an hour, it follows the show's format of technical, developer-focused interviews with builders working across interoperable and cross-chain networks. The discussion sits within The Interop's broader focus on the Cosmos ecosystem and the infrastructure connecting separate blockchains.

Speakers

Topics

Transcript

we're live my guest today is booty Unleashed CEO blockless blockless is the infrastructure platform to launch integrate and secure networks and applications at unprecedented speeds in today's conversations we'll discuss the modular application architecture randomized node orchestration Dynamic consensus scalability of general computing and building ZK verifiable applications I'm also dying to find out why she thinks applications shouldn't use one consensus and verification method but should a sample from all of them before we get started make sure to hit the like button hit the notification Bell And subscribe to get notified when I go live every week and remember that none of

what we discussed here on the interop is investment advice and if you enjoy this content please consider sticking with us for validating on fmos Quicksilver osmosis Juno and nolas just look for interrupt in the active set my guest putian is coming up next right here on the interrupt [Music] hey hey how's it going hey sip good how are you really really great I'm really glad we

can finally do this we've been talking for several months now and I'm happy that I can finally get you on the podcast um but yeah before we get started uh I wanted to ask you how has you been your uh your EU trip so far I know you were at Etc at nebula Summit and uh traveling through Europe I think for the first time so how's that experience been yeah it's amazing I'm seriously considering moving to Europe I'm currently in liege still recovering from The Craze of all those great events um nebula Ahmed eth CC and everything has been amazing um yeah can't wait to you know hit the road again maybe sometime later this

month to go back home and then wrap up things and move over at some point well cool yeah I feel like there were a lot of people at uh at HCC this year I don't know why but like weeks before Etc you know like there were the Civil level there was a civil unrest in France and a lot of people were like fighting France and and uh and then everybody got here and they're like things are amazing I love this place I want to move here and so it was it was kind of like an interesting uh to see the contrast but um yeah so this is actually like the the first post nebular episode um so um yeah what did you think of the conference maybe uh uh fomoing those who missed it

yes for sure it um I have to say it's one of the best um you are always surprised by the sheer amount of energy and Technical expertise um that Builders especially in the cosmo ecosystem I think it's one of the highest grade of uh builders that you can find and it's really great for us to be part of it and share all the um thoughts and hearing what other Innovations been going on in the industry yeah yeah and it it was funny just like the day after an ebular the you know we all we all left nebula are super energized and like there was lots of great people there all kinds of new

ideas great conversations like the whole ecosystem showed up and everybody was super pumped after even after like 10 days of Etc and then like the next day this coinbase article comes out like fighting the whole space and uh yeah it was just like well where is this happening I mean we're like this sentiment really didn't uh uh sort of echo for me I think uh generally like a nebular and all the other inner chain Cosmos events that happened during ECC so somewhere someone's not getting the memo I got a suggestion actually if you would like to consider running nebula elsewhere across the globe as well just like how you know we got CC and um other like

um Berlin Etc so if you are considering of taking it to the US maybe um I can help you out there it's just great energy and I feel it doesn't do its Justice to be only posting in Europe yeah yeah like this is definitely something we're we're thinking about so we we had one experience with a side event in uh in Medellin uh during Cosmo verse and you know I mentioned at the end of of uh of nebula this year that we'll definitely do a side event at Cosmo verse and we'll probably do other side events like during big conferences um but yeah like everything is kind of influx right now we're still

we're still kind of strategizing after this event you know and like thinking about what we want to do with it and where we want to take it but I think yeah there's definitely an opportunity to do more of these and uh yeah and and and and build out this event as something that you know is a broad like a much bigger community of people and there's you know and you know I don't want to make this whole thing about neighborhood but there's one thing that I think I took away from nebular is uh and something that I want to really make um kind of an integral part of the conference of the conference is I I want to make it such that like you have all these really smart people like building Cool Tech and like interested in in in blockchains and crypto and have uh also

like artists be integrated into the conference in some respect so we had this graffiti artist that was there during the event he did the artwork for the uh for the t-shirt and then we auctioned off like this this the photo the sort of like the GIF of this nft uh sorry the GIF of this art right that he did that was kind of the progression of the art and we auctioned it off on stargaze and we made like we auctioned it for like two grand in the end uh and and that was gonna go to charity so like I felt like that really um created a really cool experience for people to see that art being made throughout the conference and then like you know the final all you know the Final Act of that is that we get to help like all these kids with diabetes right

and um and I think that that's something that I want to try to like keep within the conference is like also art and like maybe doing good and yeah so yeah lots of ideas uh that came out of this year's event so um yeah let's talk a little bit your background and how you um how you got to be interested in uh working on decentralized compute and uh and founding block lists yeah so my background um started well in crypto back in 2017 started working really uh real world asset project but back in the day

um that isn't even a thing um been building really taking that project off the ground and to scaling really over 10 million GMB per year and then we later got listened on exchanges like Finance Etc that was a wild ride but um because there's like all kinds of government regulations and everything is super untie crypto so but that makes me really want to you know um see what in the world where you know the entire blockchain really fits in um so I went back to school and as I was scouting deals for NGC Ventures um I came to learn about this cool

project uh which um now my co-founder actually Derek he was building um he got this idea because of a Twitter threat that has been brought into a lot of discussion into sharing a decentralized network for doing General computation to support such as Dex or aggregations of tax and other kind of uh computations that is impossible to run on chain and um as I started really helping Derek out more and more um I at the end as a result I invested myself LL to helping Derek to build now a block list yeah

um he came from distributed clout space even before crypto um and back then you know he was working at Akash leading the one of the biggest distributed Cloud platform and he later find out that with a webassembly technology the industry can see really a secure run time that's like closer to like a te um in terms of you know agent Computing and he was leveraging uh the web assembly technology to build now uh blockless yeah that's cool I've talked to Derek and he's got really an impressive

background and uh you know when when we first started talking it just it made so much sense to me and and still does right like that you you have this um like uh Akash I mean block list to me feels like an evolution of the Akash idea that's a lot more specialized and and um and and potentially quite impactful in the in the web 3 stack was like Akash is uh this Marketplace for um for well essentially like server architecture right so it's quite generalized so they're doing like you can deploy like Docker containers there but they also want to get into the GPU Market but but blockless really

addresses the issue like computation like off-chain computation and verifiable option computations as well and of course in in decentralized applications that has like a lot of of use cases you know but for me it's still it's a little bit fuzzy where blockless sits in the stack right like um and maybe because that's also because the stack is is evolving and the narratives around the stack are are becoming clearer but um yeah talk a little bit about you know the the modular stack you know we know I think like what the layers are there right like we have consensus is in the A

and then we have settlement and execution um and of course we can go more granular within each of those layers but where does uh blockless sit and you know typically to whom would it be a um a client or who what what layer of the stack would it be serving specifically yeah I think that's a definitely a fair question as a matter of fact when I go around talking to crypto people about what block list is doing you know the kind of unsaid assumption is that you would be talking about something that happens on chain um but we realized that we talked so much about modularity but it's confined to modular blockchain uh but what I

think is kind of like doesn't really make make much sense is modular blockchain itself is actually not so modular um well the reason is basically in a modular blockchain architecture right each task um they should be specifically they should be specifically performed by each layer and the remaining task you know can be taken care to offload to other layers right so they're commonly known different layers as you mentioned um D.A settlement or execution which is really an after direction of sequencing and smart contract layers but actually

there are more fundamental things level below what we talked about that we almost take for granted like how we breathe the air without even knowing the existence of it such as P2P Network layer consensus layer and of course the security layer right so the idea of modular blockchain is different layers can be replaced and altered independently but this is not really the case in practice for example like we notice that an IBC for example if you want to IBC compatible chains to you know perform certain tasks form a bridge they have to rely on the underlying relayer operators to full to perform

this predefined task according to the rules right but the node may fall short um or the Inland fell off due to you know missile alignment and economic incentives there's a data point I think once read there are like almost 40 percent of the cosmo operators they quit due to insufficient incentives over time so majority of the cosmos operator for example uh they're running you know those projects that can bring them um enough profit such as Juno osmosis or secret Network just donate a few of those big players out there

um however yeah and validating on all of those chains is not always profitable yeah so I not even that and like think about for the smaller players you know they have to overcome the coast art problem you know uh they have to just compete with those across the entire proof Cosmos operators right um so um you know this is like not so strictly isolated the problem using modularity right um so it's easy for um like people to build the stack but without having it actually works I remember um ICS 29 was part of the initiative to just introduce the relayer

and middle work middleware um economic to revamp the landscape for uh for the operators so those are the kind of problems that we see with within the modular stack right so um that really like kind of starts the um where we're building it's like the question uh we're asking hey is it really possible for you know all the uh applications that build across this module or architecture to remove the economic dependencies and still you know have a much broader flexibility and room for uh creation of the innovation of the to address those use cases that the

customers would need Okay so but that but that doesn't really answer the my I mean that's all very interesting and uh but that doesn't really answer the question of like where blockless sits in the stack and um I mean maybe can we talk about like a a use case specifically so like give an example of an application um that would be using block list and the types of computations that you know it might want to Outsource the block list because those computations are not efficient or are too costly to run on um on a you know run-of-the-mill

blockchain yeah so I like there that the kind of the conclusion from uh the previous explanation is that you can achieve decentralized application or network by combining the on-chain and off chain components and to give you an example why this is uh the case um for example like some of our customers are running um AI uh Marketplace or of those kind of application that requires um intensive Computing it's not something that you can run on chain right however you still want to make it um

trustless in a manner where a variety of parties that comes from a conflict of interest they would need to deal with each other and have the transparency and sometimes the Privacy even preserved for such kind of interactions so block lists essentially fit in as the full stack decentralization solution that works hand in hand with those layer ones um so together we're able to achieve a full stack decentralization for our AI clients they run their own decentralized network that's built using the blockla's infrastructure to provide trustless

computation running those AI libraries running llm inference models and also to have the clients to give them the control of their data by running on some of those privacy preserved functionalities leveraging our CK technology and altogether we provide a much more performance Network that's tailored to the client's need okay so if I'm I'm trying to like paint a picture of um a chain that might want to leverage block list so

um would would it would would an application be able to leverage block lists to create say um something like a proprietary Oracle so let's say like you have a blockchain there's transaction data happening there um that application might want to provide uh to its users some some vert like some some version of that data that's been processed right and you might there's different ways one might do that typically for a long time the way that's been done is that um the the teams will actually run server infrastructure like centralized server infrastructure where they'll be

aggregating that blockchain data transforming the data providing it as a as an API essentially with that use case be formidable in the in the case of block list where the the chain could leverage blocked us to do that data transformation do it in a way that's verifiable or the community and the users know that that data has been properly Trend uh uh transformed and then serving it back to the applications I think that's a one example and um it actually touches a pound two things one is the Oracle functionality right and the other is the need a foreign an application which in itself is not an oracle but it leverages the

oracle's data feed um to fulfill its um trading or its uh platform needs so this is really one classic example of how you would need both entry and option components and a combination of different consensus to work altogether to provide this kind of service let's say if it's just for attacks right so kind of walking through how this entirety of the workflow would um you know would run basically let's say if like I'm I'm like simply running a Dax right and I would need a quorum of notes to retrieve the price data for

let's say just like a BTC trading pair right and this um it forms like a simple data aggregation consensus right and this could be like a third-party Oracle or a decentralized nodes that are performing this task um this is just like one commonly known feature provided by Oracle but uh which can actually be taken care of by any application if they have the access um to you know to use a decentralized node and Define their business logic so if we perform the transaction right it involves a ray layer Network maybe some Crossing bridges in the middle right they form you know the um they transact the assets

and for this part you would probably need maybe a different set of nodes and perform a different set of um verification or consensus could be like bft or the classic you know CK snark proof If you just require 1o to perform certain tasks and then once the transaction has gone through the finality settlement is done on a layer one or Layer Two level right um this is taken care by the the smart contract or the blockchain and by integrating into those smart contract or the layer one or even just uh the data availability layer right uh the entire workflow is run seamlessly by combining the different building blocks from both

onshan at the off-chain world so I mentioned at the top of the show that your hot take was that you thought applications shouldn't use one consensus but they should assemble all of them and you kind of hinted here that applications should use multiple consensus and verification methods uh can you unpack that and explain what that means practically and why you think that's the case yeah um I think like it just doesn't make sense for any application to live on a single blockchain um just like how you know if we describe there's like a very uh commonly known analogy of each layer one ecosystem is kind of like a nation right

um if you are to achieve Mass adoption you got to offer it internationally right so um you gotta do either half certain um components that offers cross train um or like um operator with the um off chain so that uh you know the the data the computation um talk to each other right so that's like the building off that um assumption right if we believe that's the case then um of course the constraint uh or the bottleneck would happen where you have to conform uh the consensus that's only provided by such layer one right and um that would be the biggest building uh

the biggest roadblock you would run into there are a couple ways to solve uh this problem uh one is that you know the simplest way is kind of going back to the uh The Crossing tax analogy right um you could run a centralized Bridge so that you avoid participating in a layer one consensus uh to fulfill your application needs um that actually works very well for say for example uh binance pack crashing Bridge or usdc but it's not often the case for other applications or networks especially those that don't come with

this Authority in themselves like in the example that we mentioned where for our clients right who want to just run a Marketplace um so in this kind of cases the decentralized solution comes down to ultimately solving you know the um the execution um and the trust that you build leveraging uh the decentralized uh node or validators and um this is just like one like one example that comes all together as to explain why um you know having multiple consensus at your disposal where you can break uh your stack down into which part is more

suitable uh for running which kind of verification or uh consensus mechanism is a more efficient way to approach the modern decentralized applications that operate as like International Company do you think this this I mean does this idea going to play into the the mesh security idea a little bit where like an application leverages multiple consensus and verification methods or or is that kind of a lower layer because I guess like this idea of an application leveraging multiple consensus is

you know like deploying your application to multiple chains and like in the context of Cosmos that would be like deploying an outpost you know to another chain whereas um mesh security is more about like chain securing each other these are these are two different concepts right but I don't know if they're related somehow um I think it's that um it's more about uh breaking things down and decoupling um things right where um we still have the settlement taken care on the layer one level that's the global Ledger uh level of consensus right um but for those uh mutable operations right um You don't need a kind of a historical ledger to uh record

everything that happens right offer that kind of particular functionality right um it may just be more suitable to run just a CK snark or one node can do their job without letting the rest of the nodes across the network to know what they're actually up to so let's talk a little bit about the the technical aspects of block list so um can you describe the network topology I mean um right should we think of block lists as as a blockchain that is like a layer one blockchain that is orchestrating these different resources

um yeah and like in that perspective what is the role of you know consensus and the different um the the validators are are the validators are different from you know the the uh the computation um those who are running computations Etc so yeah I talk about the network architecture and also the different participants in the network yeah sure so uh to start off um right you're right and saying that uh block list kind of orchestrate the task and the hardware node resources right uh but instead of doing it in kind of a chain fashion right uh we basically run this algorithm uh that we call

randomized uh node orchestration and we actually initially run that as our own Cosmo based chain but later we realized that we can actually gain a more scalability by just having that orchestration algorithm or functionality Taking Care on the network level without even having a chain and what that does is essentially allocating the most suitable nodes to run any kind of arbitrary task that comes into the network that's like just are be like if they might just be like hey like you

know I'm an application I need uh five notes to run this Oracle module for example and then across the network we do a roll call and the most suitable notes considering their Hardware uh capacity and also uh the reputation of the notes according to a ELO score ranking and then we do a randomized selection of the notes to pick up that task um sorry what's an ELO score ranking yeah so that's basically like in sports where people used to have on holistic view of like how good a player in this case is like how the node is

considering their historical performances and simply take it as like a reputation mechanism that we know we have transparency into uh how what's the quality of the node essentially and um so the orchestration uh because it's randomized so it enhanced the security by um you know um to protect it from civil attacks for example um this is the case because um unlike how blockchain works right the nodes they don't have much of choice of which task to execute they only conform to the consensus

um because the result of not doing that would um you know would incur a forking right so uh the note however within the blocks Network they are orchestrated to pick up the task without knowing what they are running or what they are going to run so that's a base layer of a security and on top of that you know the um Network or application during the build phase to specify the instructions basically a set of rules the business logic uh what are the notes um responsibilities are right and

um those notes uh they perform the task according to the set of instructions and um the most common result of it is to either aggregate the result or submit in the case of CK snark proof module they submit the result together with a proof to an on-chain endpoint or like a layer one verifier smart contract and on the layer one um the results get either validated or accepted to form the finality of when the block comes out so this is kind of like a full cycle of an execution task that happens

um with the with the block list and the coordination to the layer one chain Okay so so there there is no like block list doesn't have its own layer 1 blockchain I think we've sort of established that right yeah right and so instead um block list deployments orchestrate the resource allocation to different execution nodes that are part of the block list network is that is that correct right that's right and just like The Blacklist Network I'm sorry but that just to finalize that

thought so like the block list network is not actually a network of chains it is a network of deployments yeah sorry go ahead oh yeah um I was going to say block list Network um it is um a network of nodes and the network of uh standards established uh by this secure runtime so um so that any task can be consistently executed no matter which is the node that pick up the job okay but how's it like so so this is this is where it's unclear like how do the nodes

communicate with each other and like what is the what what is the like the the central point of orchestration right like how does one inter like let's say I want to interact like Leverage block lists where am I interacting with block lists am I interacting with block list sort of on my let's say I'm an application on Archway I'm I'm interacting with the block list contract on Archway and if I'm on heavmos I'm interacting with The Blacklist consoles on evmos and then that uh and then so that's one thing and then the other thing is how do the um how do the execution nodes know to

communicate with those different deployments yeah so um the short answer is that we have a base layer lib P2P that manages the communication uh between nodes yeah think of that as just like yeah a standard P2P Network and then um in terms of the um communication with the uh smart contract or layer one chain or let's say just like any um Cosmos IBC chain right um the end point of the so the the node um from the block list Network communicate uh with the endpoint of the smart contract so this is like similar to how any RPC node would work

um this is not something that we built you know as like anything new to the industry it's basically leveraging the existing capabilities of how the smart contract and blockchain work in terms of how they have the nodes where you can run a light node or a full node for either read or read write functionalities to the blockchain itself yeah of course okay interesting and so um I want to talk a little bit more about this um this resource allocation process so as an application I want to offload some of my computation to to block lists let's say I'm like a DEX on

this Archway as an example uh I want to have a block list do some some compute on the data that my Dex is is um is producing um that that interaction between those two contracts might happen over an IBC connection I suppose um and then um block list then uh transmits say like this this computation requirement or this VM um or this this this payload to nodes on the block list Network to pick up that

computation can you get a little bit more in detail about why um why oh sorry my camera just dropped but yeah essentially uh how um that process of choosing the nodes uh happens sure yeah I also see there's uh no signal sign yeah yeah yeah so the um for kind of a application um or like let's say a network that leverages uh blockless um I think in your example it involves like cross-training operations uh might

be some uh complexities in that but if we were just to reduce that into a minimum set of requirements say a simple uh like single chain um application right um it um it has the um let's say it has the um the business logic defined and and implemented both in um on chain as part of the smart contract right and um also does the set of the computation that's written um in like for coordinating you know the um either like say that being um a

decentralized data caching for example um like I think it's probably easier if we just like use a concrete example um some of the block list customers they are yeah so they are using block list as the um compute engine for game rendering um because you know the you know it's often this a big problem where uh fully Unchained games they suck in experience whereas if you don't put the game on chain you kind of have the centralization risk right so um these days we see a lot of people

actually don't looking into building a full stack decentralized application at the same time they want better user experience similar to a web 2 game so in this case right their assets are transacted on chain and it's the same smart contract nothing has changed whereas the option components when it comes to the rendering or calculating the kind of like game map for example for multiplayer game or just like simple features as you're playing like a poker group game right it requires a verification of a each of the steps

right and they use blocklas as to fulfill this anti-cheat feature to make sure that even an involves no asset transactions just like a kind of interim stab within the game right you have every single action validated by this anti-cheat engine and you make sure that it's a fair game is decentralized is the community that runs the game engine actually there's no centralization risk for anyone not even the team the founders to cheat and the asset security is really guaranteed as the the final

security Safeguard by a layer 1 chain so you really what the the projects or the application gets is the ability to leverage an existing layer one ecosystem uh volume and the community traffic and without paying too much uh for the rent for running everything on chain uh that will incur not only just like expensive gas fees but also high latencies that ultimately wouldn't ever make it possible to run the game engine yeah in the conversation that we had um previously and you mentioned that what was really cool about blocks this

is that you know the um that communities themselves could essentially uh uh run blockless infrastructure right so in the case of a game you know what would be anticipated or expected is that the the players themselves that you know have especially in the case of web three game right where like players have assets and there's like uh they have a an intrinsic um uh incentive to um have the game be running and everything that sophisticated players uh or members of the community could run blockless nodes and be running some of that infrastructure and of course because we'll get this we'll get to this in a few minutes because it's verifiable

because it uses as EK wasm you know essentially like only one person could be doing this right or like you know even like the company building the game could be running uh this infrastructure now of course there there might be like a liveness risk by only having like one node but um uh but you like basically a few people in the in that system could be running infrastructure and anybody could spin it up and I think that's that's kind of cool because it also provides potentially means for you know those folks to make extra money um through running this infrastructure um so that brings me I guess to like my next question which is um what what are the the liveness

guarantees when utilizing block lists for an application are the computations run you know on on multiple nodes so such that you know if any one node goes down like another node will pick up or are the computations Run simultaneously and sort of like provided uh to to the application can you talk a little bit more about that sure yeah I think you actually touched a pound a cup of important uh Concepts the first one is the liveness of the application or the network for example um with blockless you know the builders they can have the confidence that their application is up running 24 7. uh just

because we have this file tolerance or failover uh built in and default tolerance basically what it means that is that say if just one node um that goes down right the next node would immediately come up back online to pick up the task and if in one note they excuse me everyone know that they mess up for some reasons right um the uh it would not result into the failure of the application so for those kind of unexpected events um you know Builders they can't have the confidence that their app is running um even when those kind of unexpected

things happen and another thing is like really kind of stepping out of the ram of um the technical failures that would possibly cause a system to go down right uh we actually have another set of failures that we need to think of um for example like what we kind of talked about and the cosmos operators kind of problem is that you know if your nose get don't get incentivized that much it's possible for like even a layer one to go down right or it um experience certain attacks that works against the advantage of their economic incentive right those

are the kind of issues that we also try to resolve by leveraging the decentralized ecosystem economic layer and it's possible for even a project to fund a dow to run say for example their front end so that way you know you can make sure that even in the face of you know censorship that would pull down the would tear down the um the website you still can have the community run front end to guarantee the access and to make sure that the application is up uh running for those kind of extreme cases

yeah okay that's that's pretty cool um and I mean I I'd like to talk a little bit about the um the VM and like the the the the the aspect of wasm here so I think this is something that was really interesting to me when I first started chatting with you guys is uh the fact that you were using um wasm instead of um say like Docker containers or something like that and after speaking with Derek what would he explain were some things that I didn't really know about wasm was that awazen was actually pretty Compact and efficient and the the payloads are much smaller and then

there's this other thing that uh we discussed that I I didn't know about waslam which was that um and I might be getting this wrong but but wasm it's possible to predict the computational cost of a wasm um program and that makes it really kind of useful in the context of a blockchain where you have you know kind of like to figure out the cost Etc so yeah can you talk a little bit about the uh about about wasn't generally and how it's used in in block lists and some of the reasons why you chose to go down that path yeah sure so a couple of advantages that comes with webassembly or wasm and the YC interface

is that uh first is um like you said extremely uh efficient and uh portable so a traditional like Docker image let's say if it's like 200 megabytes in webassembly uh format it could be like two megabytes and webassembly as this low level uh kind of binary instruction they work across platform so any device that can open up a web browser can technically run a wasm based hour runtime node and we're really talking about a cross-platform from say running tasks on enjoy phone or

um you know even um on your laptop in Chrome or say uh very performant institutional grade CPU GPU those kind bare metals and servers and is consistent across different devices so at block list we build a webassembly secure runtime and also an ax86 emulator within the runtime for both running you know event driven and continuous tasks and the security that comes with webassembly is that is a secure sandbox environment within the host machine right with the end-to-end encryption and MPC currently we use hashic core as part

of the implementation also trying to integrate a lit later on but all those combined together we have a secure runtime even if you know the you're the host machine owner you can't see whatsoever is running on your machine and this runtime is like one instance but replicated to each and every other Hardware to made out to make up this really Global Ash Computing Network and um so building with all those um you know the Technologies plus the provision for Hardware resource

consumption basically what it means is that once a um function or a task that comes into the system even prior to running that task we can provide an accurate provision of how much of the hardware resource will be consumed and what is the requirements for the hardware so that really allow us to be I think the only provider there to be able to really orchestrate any task in a random fashion considering the hardware resource consumption and the variety of the node out there so with

all those really we allow um like you know application or network to kind of build once and then um you know go on autopilot mode to half the um the application running um across the network okay no that's really cool and and um and is is CK wasm are all applications running on block lists automatically kind of privacy preserving or is that something that applications choose to to deploy as and is deploying a wasm application or a ZK wasm application any different

than just deploying a wasm application like for developers what what is the difference there yeah for a developer's perspective right um it is a combination so you first need to of course prepare all your code that has all your um all your logic and you need to indicate which uh verification or consensus mechanism is needed so and the graphic interface that we provide for independent developers is really kind of pick and choose which one uh for which function and for our custom build solution right um it is um you know the you can have uh

the ZK or the uh the other verification mechanism um you know uh if you select that of course for that part of the logic um it uses uh now we currently integrate it with CK wasm but there are a couple of other uh CK solutions that we will later integrate as all provided as the options for developers to pick and choose whichever is more suitable for their particular application or network tailored needs and yeah so in short it's it's not like every single function or task is the same it's really uh like providing the flexibility

um for developers to customize based on their need and and will you provide like um sort of like an SDK for application developers to interact with block lists I mean I guess there's like two layers right like one is like interacting with your application leveraging in order to leverage block lists and then there's like the actual kind of computation or like program that you want the wazen VM to execute yeah yes we have the SDK um and I think it may be helpful to really um introduce a bit about our product offering um as it's a spectrum from custom built solution all the way to fully managed

hands-off serverless functions so the first one of course with the SDK and everything there are more tailored um you know logic built-in and requirements that oftentimes you know we do with bigger projects and clients we together build those features for example when they require a privacy preserved features for running a particular library that needs to be integrated within the blockless runtime right we're asked for you know the um fully managed hands-off serverless functions right you have those

is less it's less customization that you need to do whereas there are more templates that you can pick and choose and avoid building from scratch and through this approach really the developers they really just need to focus on you know the defining you know how they want the application to run and then the rest is um kind of offloaded to the network to the predefined instructions that's provided by block list to make sure that their tasks are executed correctly and consistently across the network

very cool um yeah let's talk a little bit about this this this um this random node orchestration aspect um and uh yeah how you you do this uh this random orchestration so um when it comes to the random note orchestration um so we uh when one task that comes into the system um and uh there's like a roll call that happens um to recruit all the qualified nodes and based on the function or the applications requirements uh we select

those um the number of nodes fulfill the requirements and um the task is retrieved from its destinated um decentralized Storage storage we currently we have the default of ipfs storing those uh the code logic and uh the nodes they go on execute the tasks and then compile the result and send it back the randomized orchestration means that each and every node the iPhone is fulfilling the hardware requirements would have the equal chance of being selected for a round of execution so that not only

guarantees the security but also provide the fairness for the network as to you know when at scale right um it's kind of like this Uber platform where asset driver you can fairly anticipate and expect that your car is busy all the time and you can make exactly based on the capacity of your car okay and and so there was something interesting to say so you said that the payloads are stored on on ipfs so basically like a node will look at a program whether or not they they're a whether or not they're able to execute it but like so that data also the

programs themselves are uh are hosted in a decentralized uh unintentionalized Network okay yes yes so the all those um payload and everything they are stored and retrieved and uh decentralized uh fashion um to really avoid any centralized risk that's introduced uh into this entire system as you know like the degree of decentralization or the level of security is really determined by the lowest uh you know the lowest uh components with the um any kind of risk cool

um well I I I know we're cutting it a bit short but I know you the office you're in right now is closing and um you uh you need to to to wrap up um but yeah let's let's uh maybe just finally like uh where can people learn more about block lists and give us a bit of a sense of you know the the road map and um yeah what's next for you guys yeah I think I can definitely share the link tree that uh direct to all of our documentations our developer dashboard and everything that you could find and want to find about block lists and in terms of the roadmap uh you know we are

now uh I'd say focused um majority of the time and effort and supporting uh our B2B clients and um we have a running full self-servicing um developer portal where for anyone you know really there's no uh kind of barriers to start coding and building using blockless we are extremely web 2 developer friendly as well as any essentially any um webassembly based uh or web assembly compatible language you know we have currently we have uh support for rust and python that's

coming uh right away I think as in the next week or two and also um in the future we will also support more languages including you know C JavaScript Etc and um on the roadmap I think the the biggest uh one of the biggest Milestone uh that comes up next is the launch our the lounge of our public beta test net that will open up the entire network for anyone that has um you know a laptop or some piece of Hardware to run a node um also support you know virtual node

and um then after that is integrating more extensions and everything to um you know go after the mainnet lounge cool well um thanks so much for coming on I learned a ton about uh about block list today and like really looking forward to learning more and um uh also uh good luck with the upcoming Mainland launch yeah thank you sip thank you for having me today it's been a pleasure