 Yeah, so today I will talk about the North is safe. I will essentially talk about just about one smart contract We have been working on this contract for over one year now But the implications of this one smart contract are hopefully quite significant for the theorem development and the user experience so First question to ask like why are we actually building yet another wallet? There are so many wallets out there, and I guess many of you have installed maybe even couple of them So why do we put so much effort into this and the reason is that we are significantly different from all of them because We are the first smart contract based Wallet for mobile we try to make smart contract based wallet accessible for everyone as a default way to interact on the theorem network So what are the implications of using a smart contract? Let's look into like how are all the other walls currently interacting they're using the account model where you have externally owned accounts which are Controlled by a private key that users hold and then you are signing a theorem transactions with this private key And then the transaction are broadcasted and mined What is the issue with just using this externally owned account as your as your account on a theorem? There are mainly two issues with this one is You have to have proper backups of this private key if you're losing the private key you do access to your account and The other thing is Yeah, there might be also benefits to that like you can ensure that no one will be ever able to access this again But for the most part For the most part people will be quite frightened if they see oh, I lost my private key and this happens quite a lot If you talk to all the wallet providers, which are using externally owned accounts They're quite a lot of issues popping up with oh, I lost my password or I lost my Backup can you help me restoring my account? No, sorry. We can't you just lost everything so that's the unsolved issue today and Smart contracts are where we can try to tackle this and I explain you in a minute. Why so another thing is We have not really any way to have proper access control if you have a private key Yes, you can access just everything so imagine the future of course your private keys Not only your key to access your funds, but of course it's also representing you on different dApps social networks will be used on SD apps and you are represented always with a private key if you're losing it you lose everything you lose kind of your digital identity and Yeah, another thing is also you are not able to private key to do fine-grained access control You could never do something like what you can do today with your credit card where you say Ah, I am okay with just withdrawing a certain amount of money On a daily basis, but if I want to withdraw more then I have to have additional security measures in place So future the future is contract accounts at what we are doing and The good thing about contracts is you can implement all kind of logic obviously into those contracts And this is because contracts are so-called first-class citizens in Ethereum meaning They can perform the same operations on the theorem network as an externally owned account as a private key controlled account So let's just look at how this actually works Yeah on the top the external account you just sign your theme transaction. That's it. That's what we do all the time But the more interesting part is a contract account interaction. What you do is you are Signing something called a meta transaction Yeah, so you're signing a transaction, which will be executed from the wallet contract account from the proxy Contract account, you know and of course this meta transaction has to has to be Broadcasted to the theorem network and still someone has to sign this But this doesn't necessarily it certainly has to be the same entity as the Entity signing the meta transaction so Let's look into meta transactions How do they actually work? So if we are sending this meta transaction wrapped into a regular Ethereum transaction, then it will trigger an Execution on the wallet contract and the first thing we have to do is we have to ensure that this meta transaction Was signed by a party that is allowed to trigger this transaction from the contract So what we have to do is we have to validate the signatures which were sent along with the meta transaction and These like the standard way of how we implement access control on the notice savings by just implementing a regular multi signature wallet so and out of M of those signatures that you are providing in your meta transactions Have to be from valid owners of this contract to allow execution of the meta transaction from the contract and What we allow is two different types of Signatures one is something that we call contract signatures Usually smart contracts, but they don't own a private keys They don't cannot sign anything, but what you can essentially do is you can require that this function will call an external contract and ask if This contract gives permission to execute the meta transaction So what this essentially means is that you can have different safe contracts Being owners of other safe contracts So you can have nested saves where some saves are owners of other saves This might be interesting if you want to build organizations. We have different departments with different Employees and they should authenticate specific transactions and then they can Be part of another multi-sig which is an overarching multi-sig to govern a bigger part of the organization The other signatures that we allow is just regular ECDSA signatures Those signatures are just the regular signatures that you have on Ethereum simple private key controlled accounts so the next step is of course just executing the meta transaction and Yeah, what the notice safe allows you to do is it allows you to do all the operations that you can also do with an externally owned account like previous multi-sigs they usually were limited to Doing call operations meaning they do an internal transaction to another contract What we also allow to do is to directly create a contract for example from the new multi-sig Or to execute something called delegate call meaning you can actually extend The functionality of the safe for the period of this transaction execution to embed new logic during the execution call The third part and that's probably one of the most interesting improvements is That within the meta transaction execution we allow to send and refund to the party who was submitting the transaction and What are the implication of that so previously when you had a multi-sig contract and we had owners which had to sign had to had to commit to Like let's let's go back to the previous notice multi-sig that you may know you had different accounts which were Which were Sending and yeah transactions to confirm transactions and they all had to be funded with ether Now because we have the meta transactions. You just collect those signed messages. They are sent and then you still had to In order to send this Ethereum transaction You still had to sign the Ethereum transactions which has to be signed by an account that holds ether In order to incentivize miners to actually mine this transaction Now what we can do is we can define the meta transaction That we refund whoever is sending the or whoever is signing the Ethereum transaction Which is sending the meta transaction to the contract to? refund and we can do this with two in two ways we can refund in ether or we can refund in any ERC 20 token and Yeah, so this is kind of Like an overview how it would how it would work or how it works So we have the meta transaction that is signed by anyone who is owning the wallet contract account and Then someone has to send those meta transactions to this contract in an Ethereum transaction and Yeah, this is your transaction has to be signed by someone and This has to be signed by an account usually which has ether So we can incentivize miners to mine this transaction, you know, and there's currently like a group working on Relayers where we can send those meta transactions to which will then actually sign the Ethereum transaction to broadcast The yeah meta transaction to the Ethereum network and actually make the transaction happening in The future we might see that Meta transactions will be mined or will be directly mined by miners So having those relays is just an intermediary solution Now you just have to have someone with an account that has ether on it to send this transaction But essentially if miners would be able to to merge the pending transactions that we have on the theorem today With meta transactions that are pending They could actually just yeah sign those and not even having to require Sorry, and would not even need ether in order to process them because they are the miner who are actually mining This block so they can just include those transactions the implication of this is That you actually remove kind of like this one very concrete use case for ether itself Because today the value of ether or the reason why we have ether is and why either is used is because It's the easiest way to bribe miners to mine your transaction theoretically you could try it to send them money with PayPal, but that's just not feasible so Now because users can just say okay, I will refund the miner with my ESC-20 token actually Ether itself Is not really required for this anymore So what are other like implications of using smart contracts account that have a significant impact on our dApps Something that we can allow is batch transactions So what we can do is we can instead of Signing one transaction after the other and broadcasting to the network. We can now Combine transactions together and send them as one Ethereum transaction So here what we do is basically yeah, we we pass the like we pass all transactions as one byte array And then we have to pass it and then execute all the single transactions And a couple of advantages of doing this one is It improves usability like today if you're using a dApp Then usually interaction workflow has at least involved at least two transactions one is You have to for example approve a token to a contract and then you another transaction to actually call the contract And use the token for whatever the contract should be doing Now we can combine all of them together and execute them at once So the user knows the whole business process is executed or Not know or not a single step of this business process another advantage is That it also reduces gas costs so in Ethereum for every single Ethereum transaction You have to pay 21,000 gas as fixed costs if you combine them in you have this cost only one time Third advantage is that it allows you to do to have Automicity of transactions. So for example, if you would like to do an arbitrage trade between different exchanges You would like to have all transactions executed or none of them. That's only possible With such kind of concept. So we talked about access control The default way to control access in the node save is a regular multi-sig But we will also allow to have to implement and extend access control using modules and Modules are basically like additional contracts which have to be whitelisted in the multi-sig in order to execute transactions from the multi-sig and One very interesting module that we that we envision will have significant impact is of course recovery of the account recovery of the multi-sig itself So how could in the recovery module look like so here? We do something that initially was I think invented by you port. It's called social recovery the ideas that you have Yeah, you have a group of friends and if they collide and agree that you lost access to your account then they allow you to change one of the owners of your account and And yeah, that's what we do here basically So first we have to ensure that the transaction that you want to execute from the multi-sig is a swap owner transaction where you exchange the access and Then we have to check that it was confirmed by the required amount of friends and then we can actually execute this transaction and This is just one example. There could be like lots of different kind of modules Lots of different kind of recovery mechanisms that people have in mind that could eventually work So far we Have not found yet the silver bullet for recovery yet, but we think like a smart contract based Wallet will be the foundation for this for sure because it lazy Lazy foundation to have different sorts of access controls Another thing that we are also innovating on is proxy contracts So one of the downsides of using of using a smart contract based accounts is that Creating those accounts and creating all those contracts Can cost quite a lot. So with the current multi-sig notice multi-sig it costs about I think 1 million gas to actually create another instance of this multi-sig and this is because The bytecode for this multi-sig was deployed over and over again Since one of the recent hard forks We are able to actually implement full proxy contracts and what a proxy contract essentially does It implements only one function the fallback function which relays all the transactions sent to this contract to another contract Or like load the logic of another contract and execute this logic within this proxy contract So essentially it behaves exactly Like what we call the master copy Which in our case has all the logic that the safe implements But it requires way less bytecode because the only function that's implemented in this proxy contract Is this one single fallback function? And this allows us to create new safe contracts very efficiently. It costs just a few cents today to actually create a new multi-sig contract One should allow basically anyone to yeah to use such a contract and not worry about gas costs So yeah, let's sum up what are the advantages We are able to create fine granular access schemes What is currently implemented is just regular multi-sig and two-factor authentications what we essentially use for our own clients You can integrate all kind of new access schemes like recovery options or daily limit transactions You can pay transaction fees now Not only ether, but you can use any ESC 20 token and Yeah, you can also improve UX on your own dfs by using batch transactions And there are probably many more advantages if you think about like all kind of different Different modules that you may want to do So are there any disadvantages? Surely there are so execution costs are slightly increased because now you have the overhead of sending meta transactions having to Check more Signatures eventually if you require more signatures to be validated So this all adds up, but it's not very significant The biggest disadvantage That people so far saw is that if you are using such a contract account You are adding a new attack surface because you have this additional code in between and because this code manages everything that you have It is very important obviously and well in the past we saw that this was this trust was not always justified So what did we do to in order to make sure that our code is actually trustworthy We did yeah formal verification of our contracts so That's Yeah, what we did is we started like basically the discussion started already last DevCon in Cancun where Phil Dayan Was asking us If you want to do form a verification together with yeah runtime verification because this contract In his point of view was as important as the Casper contract and yeah, so we started talking to runtime verification and fortunately thanks also to the Ethereum community fund and the noses ecosystem fund. We were able to fund the Verification of our contracts. So what does runtime where what does formal verification actually mean for us? So what what you have to do for formal verification is first of all You have to create a mathematical specification of what your contracts actually supposed to do and This ensures two things I would say first of all You are very clear about what your contract should actually be doing and Also, I think in the future for sure it will lead also to a very simplified smart contract design Simply because doing formal verification is a really really time consuming process So right now it's still not fully completed, but we expect it to be completed and maybe about Like two weeks, but there are two developers working full-time on it and takes them about two months to get to completion for just one relatively simple contract Yeah, so it doesn't mean that the contract will never have any bug No Probably not but the the big advantage is that We kind of did like an additional implementation of it and very find that we came to the same conclusions So the likelihood that there are that there are bugs in this contract drastically decreased And it's kind of like the highest standard of security that we can provide today for smart contracts currently doing formal verification still a very time-consuming and costly process, but I think in the midterm future Costs for this will go down so low that it will actually be as Expenses as doing a regular manual audit today. We have already like several releases of our Android and now also of our iOS app. So actually you can go to safedosnosis.io and you can download the Android or iOS app on your phone Currently, it's limited to rinkabee. So please don't send your Real ether to those wallets yet however, we are going to release Mainnet versions in about two weeks when formal verification is completed We don't want to go on Mainnet without Having this process being done. We also have a browser extension and you can actually pair the mobile phone with the browser extension which allows you to to not only Interact or with df that are Accessible on your desktop browser, but the browser extension can also serve as a two-factor authentication Device so you have one key in your browser extension and the other key on your phone And you require both in order to send any transaction. It's kind of the simplest possible Way you can today set up a multi-stick for your personal use We also want to get the developer community involved. So we have several bounties up on gitcoin Two bounties that I want to mention So we were talking about the yeah about modules to extend the extend the functionality of our wallet and One very obvious module that we'd like to see is a daily limit module for your C20 tokens Basically user should be able to define I am okay with withdrawing $1,000 worth of tokens and ether on a daily basis Without the requirement of two-factor authentication But if I want to go above this value, then I should always have to have to send or sign with two devices So yeah, I think I'm not sure if these bounties actually still available because people were signing up for them very quickly But definitely check it out anyways and we're going we're going to publish more and more bounties Yeah, that's basically already it. I think I may have time for like one question or two. Yeah, we got time for a question Great presentation. How do you design for trust in the recovery module if your friends become adversaries include? Yeah, so again like we haven't really figured out the recovery problem yet but what will most likely be a proper solution is to Combine something that's called parallel to this proof Together with an additional authentication requirement So parallel to this proof would work like this that you kind of have to prove that you don't have access to your wallet anymore by sending transaction with a bond let's say 100 ether or less to And this bond can be slashed in case anyone can send a transaction from your multi sync But if no one can do this within a time frame that you define that say month or so Then this is a very strong indicator that no one actually still has access to this multi-sig So this could be one component of it, but it also has its law because If I know that you are going on vacation and you will not have internet for one month Then I could exploit the situation I could send this transaction and then I know because you will not be able to react to it I can take over your account within this time frame. So ideally you would like to combine multiple solutions. I think this This parallel to this proof works for sure if you If you wait for a very long time, let's say one year But of course the usability is really really bad if you lose access to your account and you have to wait for one year So ideally we can combine it and make this time frame very much shorter if we for example allow friends to additionally Yeah become like kind of combine this kind of proof together with social recovery This should make it way less likely like if your friends basically have to first agree on that okay, we gonna We gonna try to steal your account But first of all we have to send $10,000 to the account which will be slashed in case our friends is coming back from occasions earlier Seems very unlikely, but yeah, we haven't figured it out yet But we will try to come up with some specifications until the end of the year and of course would like to have feedback from the community