Henri Binsztok 🛸 Alternate Frontends: Why and How

[Music] the the original full title was uh alternative front ends and decentralized front ends why and how and we just shorten it to Alternative front ends because uh every talk that we had until today uh shows that front ends should be decentralized so that without saying so we've seen uh that we can deploy decentralized front ends uh and using e limo until the process uh support properly ens resolution but then ens to ipns to to ipfs so basically we have a way to let's say ensure that uh from a domain we are pointing to the right resource but what's the resource exactly so talking about front ends uh we take the source code uh which can be PR big we'll get back to this uh we generate build artifacts and then we store these artifacts on ipfs but if we look a bit more precisely at uh the source code of these artifacts which are now safely deployed on ipfs in a decentralized manner uh and we look around it we see and we find some links to uh here let's say uh an API uh and here it's it's normal ipfs and uh if we look use some tools like built with or others we see that this is pointing to an ec2 instance uh which basically uh does not fa the the the build enough so when you're a project you're writing your smart contracts you deploy them on chain that can be properly decentralized of course and there's many many talks on the L1 that just finished now uh the front end itself the build artifacts you can put them on ipfs uh but there's also uh an API and which is not decentralized at least not by default and and not quite often uh and I would say one more thing is uh the client code uh can be responsible for doing the the RPC calls and managing the RPC codes and uh even vitalic mentioned it that the nodes themselves uh the decentralization should should be uh well thought and that includes the way these connections are written in the clients themselves so decentralized versus alternative why alternative go as well beyond decentralized uh project can be maybe forced to to to shut down uh front-end operators might have legal risks and uh teams can can lose interest as well abandon the code base so we see from inance the the market going from bull market to Bare market and some project disappear but the smart contracts they they they're still they're still on basically uh users if it's a defi project can still have liquidity that they they can freely withdraw using the contracts but if there's no more front end for many users uh it will be harder to to to do so that's why the uh importance of having alternative front ends uh matters for everybody and especially for the users and the main question then is uh how can we trust these alternative front ends uh and how can we trust even Beyond The Bu artifacts the API um knowing that uh for a reason of client diversity which will definitely help us uh resist censorship uh we probably need not a a redeployment of the original front and Repose so the key issue is trust and and how easily when we see a front end when we know this is an alternative front end uh how can we trust this as a user if it's not the original project how do we know that uh this frontend is safe to use and if we look at let's say a simplified architecture so we have our build artifacts we have U multiple sdks which have been embedded in in those artifacts create an interface which connects to RPC API Etc so obviously we should trust the the the URL or the the the ens when properly decentralized we should trust the API and we've seen that uh most often it's centralized and uh we should trust the RPC node and that's another thing and which is one big thing we're going to talk right now about is we should also trust the front end implementation itself uh because if you look at what's a front end and for instance this is an example of one single page of Unis Swap and liquidity uh uh which overall is 500 lines of JavaScript code not counting a lot of different libraries SDC components hooks Etc so if we include all of them we're talking thousands of lines of code to just build an interaction uh so we are including web 3 react uh here react itself lots of lots of component and what's lost among those lines is the semantics of the trans transaction that we want to perform uh what exactly are we going to compute to build the transaction and then submit that transaction and if you look you you can go on hundreds uh hundreds of lines and you have bits of the semantics which are spread in those in this C base some in the page of the method itself some in some components or Hooks and put together together you have you see Tiny bits of computation uh a bit of slipage here uh a bit of determining whether it's native e or an erc20 token uh how do we uh then call the the the estimation etc etc so the front end code is very complex and it has a lot of dependencies and because of that one of the main problem if you want to have alternative frontends and if we want to get trust in those alternative frontends is it's hard to verify and it's hard to maintain as well this codebase uh evolves permanently and and each uh update basically should trigger a whole new audit or a new look at and if you multiply this by the number of project you have hundreds of project thousands of projects on chain if you want to make sure that each of the front end that you use is safe safe there's a lot of work we thought at okay contract about one solution that involves uh building a common implementation for front ends right now project a has its built artifact monolith Project B two and three as well and the bits of semantics are highlighted in color they are here among a lot of boiler plat or or generic uh code what we should do instead is uh maybe built a unique engine which works for any kind of transactions and having much shorter specifications and descriptions of the transactions that we want to to to perform and uh that will simplify considerably the way that uh we we need to the time we need to spend basically to to look at them to make sure that we can trust them and as well we can also have a generic layer for UI generation and uh that layer will help mostly for security so we're reducing a bit of freedom on how we can design things uh exactly as designers want but we uh since it's uh automated there's less code as well to it so what's this it's trust and the second thing is minimalism and the way to minimally uh describe what uh Transaction what interaction we want to do is to specify it properly and for that we will introduce really soon uh the the the open source Repose of lambdas script which is a purely functional language that specifies a transaction kind of a let's say lowlevel intent or high level description of a transaction this is for instance what it looks for a swap uh but if you look for ad liquidity it's uh about twice the size it's still very very short and basically it says okay we're sending uh to the the the wallet that submits the transaction uh uh token a is fixed but could could be left to as a search box uh the path the deadline how we compute the amount out mean which is the parameter that the the the method uh requires and this definition basically we can uh use a compiler to generate some bite code which describes this transaction at compile time we can detect some errors if the transaction is not properly specified and then have a common transaction engines we take the user inputs and build the transaction directly from clients because of the separation of the specification and the runtime basically it's a much smaller amount of code for each project and each interaction that makes it easy to verify and the single common runtime that will fully open source of course as well uh can be multiple times uh audited and independently for instance uh now we're we're working with optimism and we'll probably try to to to audit uh on on their side and uh and several other uh people will be able to to audit that common runtime and another thing in trust is that since we have this shorter description of the interactions anyone should be able to attest that this is a correct one and for many people uh in fact that the community cares about like the project itself maybe us uh maybe chains or trusted members or or in the community or the the eum foundation who knows can uh create attestations that okay this uh interactions to add liquidity on that project is valid the computation is valid so basically we can attest that this is correct and this uh signatures should be stored on chain so that is completely separate from the rest of the apepi nodes which which provide the the the definition and the last step is as I mentioned the automated interface generation so UI matters for the end users and uh if we only have the definition that we mentioned about the semantics and then we have a common Universal runtime and a definition to UI generator as well which is common for all projects then we can be sure uh that the the there are less problem with the security of the build artifacts than uh that that we can run you all maybe remember that badgal was hacked through the front end for 120 mil what happened about two years ago was that the attas managed to to inject uh some code in the front end to to uh make approval in fact for for to user tokens to their their own addresses but they were clever in fact people started approving tokens uh and they didn't do anything they just kept the approval and just watched the approval going and when a whale came in and approved for 50 million now they say okay it's time to collect our benefit and they they they reaped every approvals that that they had so because of that we need to me to really minimize the way in fact uh we have code uh in our front ends and that includes for us no external dependencies as well uh in a similar manner kyba swap was attacked to Google tag manager and if you look at most of the project today and uh this is a discussion that was mentioned a couple a few talks ago uh about data collection and privacy B basically most of the front ends right now use Google tag manager and a Google tag manager is a vector for injection attacks as well so if we have these two engines we have our program so the the short definition of the semantics that we directly compile to a UI automatically and we also have the runtime that will from the the UI buil the transaction and that works so in the the the let's say test Nets uh that we are doing right now uh we these are actual screenshots of different kind of interactions that we can generate and so this is not fully customizable but we'll have an SDK for that which is another thing but for these interactions it's still nice enough for the end users and uh we believe it's a way to to reduce the the the complexity and so to increase the trust so if you want to uh take away two things is we talked about trust and minimalism and I think that trust minimalism is is the way to to properly build alternative front ends uh so if we look back at the architecture what we propose is to have this single alternative UI which can just take the definition uh the short definition of the semantics and build a UI for that I didn't have time today uh to mention how we can have decentralized API nodes as well for that and uh but that's definitely a way to do it so we can deploy the static builds which can provide alternative uis default front ends uh using generated UI and a universal runtime and as well decentralized the API nodes so this can create let's say a repository of interactions where we can find uh interactions and alternative uis for most of the dii or nft operations or or the new use cases that will come for for blockchain and what we will be able to have is the community vetting that the definitions are correct and independently that the common runtime uh for this interaction is correct so that's uh the conclusion of this so uh if you want to to contribute uh maybe I think uh we could uh work on an EIP to to specify the transaction part and uh really uh looking to to have also others uh contributors to to that and if you're a project uh and want to ensure you have alternative front ends we will pretty soon release everything but you can contact us uh to to be in the let's say the private uh betas uh before we publicly launch uh so you have the the RL where okay contract on Twitter and uh we just created uh in fact a telegram group if you want to join it and uh we'll probably announce things there thanks