Polywrap - Any Protocol, Any Language

ETHCC 4 · July 2021 · 22:38

Jordan Ellis introduces Polywrap’s language-agnostic toolchain for interacting with blockchain and peer-to-peer protocols. He describes WebAssembly modules delivered through IPFS and GraphQL requests executed within applications.

Speakers

Topics

From ETHCC 4, hosted by Ethereum France.

Transcript

well hi everybody uh i'm here today to talk to you about polywrap i hope you're excited i hope you're ready um the main purchase the main purpose of this project is to try and bring web3 protocols to all types of applications and so we'll talk a bit about what that exactly means in a sec first off this is who i am i'm jordan ellis uh just so there's a little bit of information about who's talking to you today um i i spent the beginning of my career working on game engines and uh and also operating systems and that was really fun uh but once the web3 bug kind of hit me i jumped into that space about two years ago um i've been working at the d or development shop ever since then and also out of that we spun out uh

polywrap into its own project and so that's what i've been spending my time on for the past like six months to a year and the reason for polywrap is the fact that over the past two years at dior we've worked with lots of different clients and we've seen the same problem pop up within all of these different web3 projects and so that problem is the web3 integration problem and so i'll talk to you today about what exactly is the web3 integration problem so this is web3 today we have lots of javascript sdks uh the reason for this is because for web3 we don't want a central server to be authoritative so we don't want that central server to be acting on on our uh on our behalf we want to be taking as

many actions as we can inside of the application since that's where our private key lives that's where our you know our domain lives where we know what's going on inside of our device or at least we think we do and so we have lots of javascript sdks there's lots of problems with this though and so what are these problems one uh javascript sdks are not multi-platform if you wanted to bring a javascript sdk into another language environment like let's say on a game written in c plus because that's you know my personal background to bring the javascript virtual machine into another application it's extremely heavy and so javascript is not portable and so that's a big downside a lot of this code would have to be rewritten in another language

to be usable um also javascript is insecure and so there's been lots of different exploits that have happened in the past where a single javascript package has kind of exploited a whole application which i'll go into more detail in a second and then the last two sorry uh it's not scalable meaning that the more javascript sdks you add to your application the larger out your application grows and so your bundle size grows and so what ends up happening is if you look at like you know the d5 aggregator applications out there a lot of them are using centralized servers right now to do their aggregation and it's because you know they're doing lots of data processing but also because to introduce new protocols it bloats the app and then lastly it's not standardized so

each javascript sdk is written differently and so i'm sure that you've probably spent hours you know going over let's say like ipfs's javascript sdk or ethereum's or some other project like like let's say uniswap and trying to figure out how exactly to construct the objects use the functions you know what interfaces and what call patterns are the right ones and each one's different because there's lots of different ways to architect your javascript object oriented or functional or you know other things like that so i propose to you today that polyrep is a solution to all this headache and so i'll walk through some examples show you the main solutions that we're presenting and how they actually work

under the hood and we're going to get into the details and please let's get as deep as you guys want so first off with not being multi-platform so this is kind of like the javascript paradigm here in order to bring your javascript code into other types of applications you would have to rewrite a lot of it in different languages that are geared towards what you're trying to do so let's say a backend service in c sharp or a mobile app in java or you know i watch app in swift and so you'd have to rewrite the same sdk for let's say uniswap in all these different languages to use it inside of your application but with polywrap that's different we can use polyrep in all of these devices all these different types of application environments without having

to rewrite your sdk so it's a single sdk that can go everywhere magic i'll talk about how we do in a sec um but we use webassembly that's the the main so anyway um this is the insecure case so you know we've probably read articles in the past where let's say some kind of crappy bitcoin wallet that lots of people were using got hacked because a single javascript package was able to go and get a private key and send it off to a server where they drain the wallets you know in ethereum we use metamask a browser extension so we think we're beyond this but in reality if there's a browser update that gets released tomorrow that leaves your browser extensions vulnerable

to some kind of like you know switchery within javascript any module like and i mean any module in your node modules folder of thousands of them could actually go through your application access the window you know do naughty things and so in the world of polywrap each polywrapper is isolated inside of its own sandbox and so this fixes that it can't actually access your application memory directly and so if you were using let's say a private key inside of your javascript which is very very bad don't do that but if you were you wouldn't have to worry about the polywrappers that you were executing because they can't actually access your application memory directly so that's cool and then on the not scalable points so

if you build an application with lots of javascript sdks performance degrades load time degrades you know a lot of stuff and then with polywrapper what we do is we pull down all of the wrappers that we need and we get rid of the ones that we don't and so this allows you to basically add an infinite number of integrations into your application and the garbage collector will basically get rid of the modules that it doesn't need and you can tell it hey keep my run time heap size to like you know five megabytes and so it it'll basically make sure that it only uh keeps on hand the poly wrappers that it's using and that keeps it underneath that threshold and so this is very similar to the web 2

world where you can add an infinite number of web to requests to your application without bloating your application it's the same kind of thing here and then with javascript it's not standardized so like i was saying earlier all these different sdks are written differently so trying to compose them in different ways like let's say you wanted to use compounds javascript sdk with maybe uniswap and also with aragon's or something like that they're all written very differently so composing them would be a lot of hand stitching and a lot of a lot of headache but in polywrap what we do is we use a standard way to define interfaces of your modules and so composing them actually becomes very simple because they all have a similar interface you can also define standard interfaces

similar to let's say smart contract standards and so you know composability uh being able to have uh on-demand kind of like extendability is really uh interesting and cool and so we'll actually get into the details of how we do this but before we do that here's kind of our blow by blow you know why is javascript way better or way worse than polywrap um you know we we really want to move the web three space forward and we believe that getting away from javascript sdks is a huge step for that just a quick anecdote i used to work at microsoft on like enterprise blockchain stuff wasn't the best thing that's why i left but um but uh you know a key tidbit from that experience is that we rewrote everything in the

javascript world that like mainstream ethereum world was using today um we wrote a lot of stuff just rewriting it in c-sharp and so like the rewriting happens it really does um for instance we've talked to lots of launch partners and i'll talk about that in the future but anyway yeah i'm just trying to tell you javascript's not the way man all right so how does polywrap work let's get into the details this is the fun stuff um so first off we use web assembly and so this is like our major cornerstone that allows us to actually do this webassembly allows us to be usable everywhere it's a very lightweight bytecode standard that has uh implementations for running it in every major language and so from

everything from like a you know small iot device that's memory constrained to let's say like a back-end server written in c-sharp or something like that or go or rust and additionally webassembly is sandboxed by default so these webassembly modules they can't access the host environment you know like they're operating in a little isolated container and so this gives you that great property of being you know shielded from whatever it may do um decentralized storage this is another big part how do we actually fetch these polywrap modules on demand like i was telling you earlier to give you that kind of infinite composability

we use decentralized storage here i'll show you an example using ipfs but we do support any uh decentralized storage solutions and so we'll talk about ipfs here first and so infinite scalability how we do this is we fetch our modules from ipfs we download them into the app they're very lightweight we recently rewrote the uniswap javascript sdk in a polywrapper and um you know the query module and the the mutation module it's like 200 kilobytes or something like that and so just really really quick to download um and then we get rid of the ones that we don't need and so with this we can you know keep our memory space low we can keep the app running smoothly

and then uh since we're using ipfs and it's all hash addressed we can make sure that we're downloading the same content each time which is really handy and then lastly we use graphql so this is our interface definition language we use kind of a little modified version of graphql but it allows you to define simple interfaces for your polywrappers and so this way you can you know compose them on top of each other you know this one could be used in this one and this could be used in this one and then additionally you can define standard interfaces with your graphql and so i'll show you kind of an example that we can talk about in a little bit so these are kind of the three main

pillars you know we have the execution which is uh portable web assembly we have the storage which is decentralized storage and also you know content address storage which is really important and then lastly we have our public interface which is graphql this is like our semantic interface to our you know runtime code so ready to get started let's talk about how we do this um and really quickly to the the person in the back doing sound uh could you let me know when we have like five ten minutes left yeah okay cool thank you so the first step is you need to add the polywrap client to your application to run polywrap modules and so it's no different than let's say

adding an http client to your application to run http requests um here we're adding the polywrap client to our javascript application and then once it's installed you simply start the client by just importing it and creating it a quick note when you create your client this is where you'll basically add any host capabilities that you want to add to your polyrep client so for example if you had like a private key for ethereum's signatures you know in metamask you would add your metamask provider here to be able to support those types of signatures that are happening inside the host environment and not in the module and then lastly we can query something

so here we have an example where we do client.query we do slash uniswap.eth and so at this ens address it'll redirect to an ipfs hash and then we'll download the polywrapper there so ens ipfs content and then here we just send a query to the module and we say we want to do a swap mutation so this is a write operation and so what this will do is the client will you know go out it will whoops it will go ahead and fetch the polywrapper using the uh the the resolution process it'll then go ahead and execute the swap function

with these arguments and boom you know like you're using unit swap right in your application no need to install the unisop sdk you can just query it on demand and any protocol is just a request away so that's that's kind of cool kind of cool and so here let's go and look at what the build experience looks like for actually building a polywrapper and so here we define the schema so this is a query module so these are reading operations we have a function called method with an argument and then we can also define custom types and over on the right hand side we have to implement our webassembly code and so first off this code that you're seeing is

assemblyscript but don't worry we're not only supporting assembly script we've actually built a tool chain so that we can support any language that compiles down to webassembly and so the next language we're adding support for is rust and so here we're showing you you know this assembly script example in the future we'll also have rust rust-based examples for building polywraps we have this method as you can see here we are importing our custom type and also our our input variables for the method and then lastly we have our business logic here and so this is obviously a very simple example if you wanted to see some more interesting demos i'll give you links at the end um but yeah let's let's move on so

the next step is composing poly poly wrappers so you can actually import a polywrapper into your own and query it um just like the application was before and so here within our schema we do a little import statement we say import the query type into api so this is a namespace from ens slash api.domain.eth so this ens address points to a polywrapper and the toolchain will actually go out and fetch that schema and add it into your webassembly code and say hey you're trying to query this polywrapper let's go ahead and add that to your generated code that we do for you that lives in this little w3 folder here

which this has to be renamed because that's from the old branding we used to be called web3 api now we're called polywrapper so this will get renamed um and yeah the the auto-generated code will go ahead and add the you know the nice function for you to call so it looks like you're just calling a normal function in your code but what's actually happening when you run this is it's sending out a query it's sending out a query to that endpoint saying hey execute this and the client will resolve that so this is really nice you know you you can have composability you can import other uh other poly represent into your own and then in addition to this i just want to touch on the fact that you can also define standard interfaces

and so we could basically say that um you know this query type is an interface and we could implement that in our module and then you could imagine in the future maybe there's some on-chain registry of implementations so it's like you look for let's say all the implementations of the automated market maker polywrap standard you know um and then building d5 aggregators is really simple um you know other things like that is really interesting to think about so these are our launch partners so the cool part about our launch partners is that we talk with them about their issues and if polyrap solves some of their issues we say hey become an early adopter become a launch partner

we will talk to you regularly um we will give you tours of what the tool chain looks like grab your feedback so that we know that we're actually providing usefulness to your use case and then we're working with them now we're getting to the point where we're actually starting to get slots on their roadmap to build out their initial polywrappers which is really exciting and so these use cases are all very interesting i'm not going to talk about all of them because i don't know what all i can talk about but just to to know all these those different features of polywrap each one of these launch partners has a different niche use case that that really requires that and so it's very cool that we've gathered kind of like a broad set of users

and these users are going to be the first ones available on the hub and so the polywrap hub is basically going to be a place where you can discover um and discover any polywrap you want so for example you could type in multisig and you would get like five different examples or five different poly wrappers maybe on different chains of a multi-sig poly wrap and you can deploy it so if you're building something you can go here to easily deploy and make sure it stays online and then lastly interact so right inside of the hub you can write and read from any of these polywrappers which is really exciting and so here we have a quick example this is a little little sneak peek we're using the uniswap v2 polywrapper

we're sending a mutation query with a swap and then here as you can see this is the successful transaction receipt with the hash and all that fun stuff so you know it's it's really working it's really doing if you want to test it for yourself we have a demo this is the uniswap v2 demo where we forked their interface and we went ahead and kind of uh we we took out all of the javascript sdk and we put in the polywrapper that we built and so it was a really great um you know stress test for our system to make sure that it actually functions at production and so if you want to check this out just go to this uri and over here is the normal swapping interface and over here you'll see the actual queries that get executed to execute a swap

so yeah thank you so much for listening i would love to spend some time on questions quick call to action follow us on social media if you want to stay in touch the slides are available right here so if you were stressing taking pictures like just go ahead and scan the slides you can get them later um you know we have docs out so please come and use it provide feedback join the discord we actually are operating as a dow and so we like to incentivize community growth and so we have done things in the past where we incentivize people to give reviews on the documentation i'm sure we'll do more of that in the future try and integrate it into your things and if you'd like to join the project because like i was saying we are a growing community um join we have funds we pay developers

i think we've paid developers i think i think it's half a million so far which is really cool over the past six months and so like we're really pushing it out there to lots of different devs we're looking to grow so if you want to join us come and join us it's really fun and yeah that's polywrap thank you if we have time for questions i'd love to talk about some things who has questions yes first of all amazing project i love it um there's a lot of protocols a lot of versions of different protocols sdks that have errors errors that get propagated through versions

how large is your depth force to be able to be up to date with all of that yeah so not at all but the idea is to build a tool chain that can help protect against those very things you talked about so for example um the concept of versioning and having breaking changes what we're doing in order to solve that is we're building a better version of npm where we're actually building a smart contract to be in uh think of it as like a smart contract based npm right where you can actually anchor specific versions and you're guaranteed that that version will never change and then through different semver you know like granularity so it's like maybe you leave out the patch but you have major and minor um what that says is it says all right

i'm opting into patches which means that the webassembly code can change but the schema will never change so i'll never hit a place where i try calling something and it says oh my schema changed you know that function doesn't look like that anymore you mean the schema of the function call yes right and so yeah there's different granularities in which we can make the version register useful and that can allow you to further lock down your dependencies and then additionally we want to build the feature where you can just run a build command for your polywrapper and say dash dash lock and it just iterates through all of your dependencies and it grabs the specifics like static content identifier for all of them and so that way you can guarantee that nothing will ever change it'll always

execute the same way so yeah yeah amazing yeah looks like time's up thank you for the question that was great i really appreciate your time and yeah thank you you