Henri Binsztok / DCxPrague

Transcript

so hi everybody hi Prague here in This Magnificent Castle hi Istanbul uh so yeah today we're going to talk about uh decentralized front ends and alternative front ends why and how and uh just as uh let's say why the title now has been shortened to just alternative front ends it is uh because uh we believe in istan okay so I'm waiting for for okay I keep saying random things exactly as as Tim suggests uh until um until we get the sound in Istanbul as

well just just ping me so when the when you can hear us uh from Istanbul um so meanwhile I I can just tell you how that the prag is is a Lov City so no I'm I'm just joking okay it's G it's okay perfect so getting back to the title so 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 goes without saying so we've seen uh that we can deploy decentralized front ends uh

and using IF limo until the proces uh support properly ens resolution but thens to ipns to to ipfs so basically we have a way to let's say ensure that uh from a domain we 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 pretty big we'll get back to this uh we generate build artifacts and then we store these art facts on ipfs but if we look a bit more precisely at 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 pointed to an ec2 uh instance uh which basically uh does not fa the the bill 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 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 uh 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 calls and uh even vitalic mentioned it that the nodes themselves uh the decentralization should should be uh well thought and that includes the way uh 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 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 uh and

how can we trust even beyond the buil 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 frontend repost so the key issue it's trust 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 front end 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 the 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 centralized we should trust the API and we've seen that 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 which overall is 500 lines of JavaScript code not counting

a lot of different libraries SDK 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 we including web 3 react uh here react itself lots of lots of components and what's lost among those lines is the semantics of the 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 code base some in the page of the method itself some in some components or Hooks and put together you have you see Tiny bits of computation uh a bit of sleep page here uh a bit of determining whether it's native eth 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 front ends and if we want to gain trust in those alternative front ends 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 projects we have hundreds of projects thousands of projects on chain if you want to make sure that each of the front end that you use is safe there's a lot of work we thought at okay contract about one solution that involves uh building a common implementation for frontends 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 plate 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 exactly as designers want but where since it's uh automated there's less code as well to edit 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 lambas script which is a purely functional language that specifies a transaction kind of a let's say low-level 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 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 input 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 uh with optimism and will 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 API nodes which provide 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 then uh that that we can run you all maybe

remember that badgerow 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 approvals in fact for for to user tokens to their their own addresses but they were clever in fact people started approving to tokens uh and they didn't do anything they just kept the approvals 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 benefits

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 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 build the transaction and that works so in the the the let's say test Nets uh that we are doing right now uh we this are actual screen shots 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 UI default front ends uh using generated UI and uh 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 we could uh work on an EIP to to specify the transaction part and really looking to to have also others contributors to to that and if you're a project and want to ensure you have alternative front ends we we'll 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 will probably announce things there [Applause] thanks do you have any questions yeah um you mentioned the very propi the vector atts uh specifically uh by the injection of the Google tech manager and

so on and so forth uh we we were having here the web stre privacy also the the Meetup before the the events over here and one of the aspects which are there referring to the D projects is that quite many of them I don't know uh due to the VC requirements or something they are using you know the Google tech manager and all these things to to identify the user adaption and so on um this is a tremendous issue and I don't know in in which extent it is being solved by the formal specification of the transaction when actually quite often this Vector is misused by replacing the two address you know uh which is then combined with the

secondary uh uh attack uh Vector attack of being of having the uh fishing smart contract which seems similar but behaves differently so um is this the formal specification which would be attested and so on uh is this also addressing this issue that we are interacting with a different contract or that we might be we might have the replaced only like the um beneficiary address so good question so basically I I I sum it up as how can we trust that uh we are in interacting with the right contracts is yeah uh uh so basically when we specify the program uh so the

the the definition of the semantics that that includes the contract so when I mentioned that the community can be involved uh like the project itself uh signing that and attesting that yeah yeah this is a genuine interaction that not only includes the the build the values computed and and submitted but also the addresses that we interacting with so if someone creates a fake token that that will show up in the short definition which anybody can review and and and most probably uh nobody that uh that is trustable Will Will vet for this kind of fake interactions yeah another

question just a second second part of the question was if there was the attack direct directing towards the beneficiary address so not not only towards the smart contract replacement but just replacing the beneficiary yeah so okay the beneficiary address then it's it's a user input and um if you see in in the definition uh let me come back here uh okay so here we see that the beneficiary is uh Dollar Self and uh what we can do is uh so for now uh we can we have an additional field in fact in the specification which are some security

rules that say that this two value is sensible and that for instance uh it should be either the the wallet submitting the transaction or somehow an address which is whitelisted for that user and uh this is just the beginning but uh there's probably a lot that we we can do in this space as well um there are some questions on the chat uh basically uh asking about how does Discovery work for websites in ipfs is there a DHT crawler um so can you talk a bit about that yeah so here in what I mentioned so basically we'll probably

want to uh for for the alternative front end so there's two way to answer first we'll have just one main deployment of the engine which takes a parameter and the parameter being the identifier of the transaction specification so basically there's uh there's not too many u in fact deployment that there should be one uh single address and ipfs CID and most probably a CID uh which has been audited and uh if we have a development version basically that's another deployment uh but the the the one that we should point to once we have

finished properly implemented a first revision is the the the the the audited one uh and uh there was a second part of the question sorry and uh asking about DHD specifically oh yeah so right now we we don't do anything specific uh but yeah of course there's there's room for improvements cool thanks thanks [Applause]