Ice Bear - We can build more than just protocols!

Transcript

next up we have ice beer the founder of geod Finance who will show us that we can B build way more than just protocols hello so I'm not going to be uh talking a lot my uh point is very clear that I don't like a protocol based developments in the on top of blockchain so far in defi I find them kind of insecure uh and I think we can build something very much secure than that so right now defi is uh in glorious days like not right now it's in beer

season but uh last bull was pretty strong uh a lot of money pouring into def and we are seeing a lot of hacks and these hacks are not just audited un audited protocols or anything audited protocols can be hacked audited protocols or other forked protocols who are relying on top of the code infrastructure of other protocols can be hacked as well so how we can solve the hacking dilemma so you cannot build something too much centralized you cannot rely on centralized code because it's safer because then we are losing

the Glorious part of defi which is it's being permissionless anyone can build on top of uh defi on top of etherium other chains and deploy their own instance of protocols so what are the causes of these problems first of all we have built products that are too complicated for uh humans to read so you cannot just assume what the smart contract does even though it's verified on ether scan right it can be something much more different because there are ways to even uh trick eer scan you cannot make sure of what's the functions name well that's even something so we have built overly

complicated protocols that is that makes things hard to verify so you cannot just assume what is the functionality of the program what's the functionality of the smart contract it's hard to maintain as a developer there are couple of tools that are making things easier for us but there are also a lot of uh missing parts in the development cycle and it's hard to integrate uh you can integrate with Unis but you cannot integrate with un's all Forks because even though there are some uh standards on what the exchange means in terms of unit of version three version four whatever uh it doesn't mean the same thing in for example Banker or

other uh exchange so we can actually build something still permissionless something that is not much complicated and something will secure ethereum uh in the onchain level and final thing the current state of defa is it is imperative so it's not declarative you don't assume you cannot understand what it's doing by just reading the documentation you got to make sure by reading the bite code or smart contract if it's uh open sourced and it's very hard to even read the smart contracts understand them evaluate them audit them and it's kind of very easy to miss some of the bugs and very easy clear

points so how we can fix them so I'm going to show one example on what is the the problem and one that we all see every day so this is who knows what is this do you know do you remember this screen you know what is this no so this is the opens up this wizard you can deploy RC uh 721 1155 rc20 as well at token and you can actually customize it which is very good because you you you want you might want this little new flushy features in your erc20 but when this happens this happens too so anyone can

uh create an rc20 and anyone can try to scam you on ether scan as well there's no way to make sure that all of these ERC sanes are implemented correctly or forked correctly from open ze's website even though there's a website for it you can just change the smart contracts and try to hack other people so we are uh at this point we are back to score one it's a permission anyone can deploy a smart contract on ethereum uh but it is very complicated so ones that have no clue on how to imp as smart contracts shouldn't probably uh deploying

them okay and this is the other part of the problem we are just forking a lot of protocols un have forked over 500 times compound forked over 100 times and all same as well uh so there's a lot of forked protocols there's a lot of money that is bound to the same code without being bound to the same smart contract infrastructure so even Unis is being hacked they cannot stop the other smart contracts who are using unb Fork version so you have one chance you can either use unb or uh there is really no interest in using

a un Fork uh because it if it's have hecked then it's probably much more hard to overcome uh it's uh burden rather than un and that happens so um there is a protocol on Avalanche called Stars Arena which is a forked version of front Tech uh it got hacked but front Tech didn't get got hacked because even though it seems like it is the fork of uh front Tech Stars Arena actually wasn't uh they changed the code so they made it vulnerable and there's no way to check

for a everyday user there's no way to check if star is a truly a secure as the fork it got uh it got him from Tech and to be honest it's a nightmare I wouldn't want to be in the uh War Room trying to fix this stuff it's really hard because it's really not that maintainable to work with any forks and uh it's not that as secure as well so the idea is how we can make defi declarative how we can say hey here is a code and we know what it's doing we don't need to check it every time it's

used but it's not the same as erc2 you cannot use all the RC 20s some can even can trick you to stealing other erc20 is in your uh wallet or some protocols can try to um use ERC 20s to trick their users and steal their money as well so you cannot use all the r20s but if we could make erc20 declarative if we could say this token just transfers magic internet money around and this is how you do it then it would be declarative we wouldn't need to check the B code for every rc20 and we wouldn't need to check uh the smart

contracts in these declarative standards uh so yeah I think there are a lot of uh useful stuff that we can uh make use of in ethereum because it's a settlement layer you can settle your declarative sentences as a smart contracts and then reuse them you can just say here is erc20 here what it's doing and you don't to change it just Fork it and have a verifiable fork of erc20 so this seems like verifiable Forks uh which is very narrow scoped uh research area in uh infrastructures part of smart contract

so you can have verifiable Forks what what's the usefulness in that how imp important it is that it is declarative so this is what it comes comes down to you can think of it like open Zeppelin but but on chain you can check the boxes you can say I want my2 to have um voting mechanism I want my to have um I don't know rebalancing uh because it's really changed over time but rather than implementing that uh functionalities in your erc20 you can just use open zeppin

erc20 but as a user I'm not going to be uh sure that you use open erc20 in a uh correct way and you didn't change anything so because of that I uh we have been working on onchain standards which means that you can deploy a package distributor and that package distributor can uh maintain the versions different versions of you know open zeppin just announced their version five for example they can just update the erc20 standard to version five and end user I'm going to show this part and user can deploy so it's hard to read it but it says deploy here so and

user can deploy an rc20 and with just one click and some modifications that is handled by the infrastructure party you can have your own instance that is verifiable as erc20 that is uh 100% safe to use because it's approved by open zeppin so this is one thing uh it creates a standard so instead of for example in this example let's go back there in this example if we knew what are the correct erc20 uh version provided by open zeppin if it keep track of the correctly implemented op ERC 20 is in just one smart contract which is package

distributor we don't need to see these because these are created by other people or this this is not um really well fit for erc20 standards because it allows other people to send money to you without their permission so this is not actually an ERC one it's just acts like1 and there's no way to verify it other than having onchain standards having that we have an erc20 model and we can verify it because it's provided by an infrastructure provider like open Zin onchain verifiable so it's that easy uh we can remove all these transactions and it would just have two real I think yeah

three four real transactions in this 21 transaction which is more than like a lot for everyday user you wouldn't find your own address these are all fishing fishing addresses a fishing address so we can just remove those by having an onchain erc20 standard so let's continue yeah so uh it's now safe to assume so this is safe to assume uh which kind of contradicts with do your own research uh you know one of the most said uh senten in defy you don't need to do your own research in thiss

because it's uh deployed by open Zeppelin just uh used by the end user and deployed by the developer who did nothing rather than just simply using the wizard here yeah so that's it basically updating those one other thing is that uh how you would make sure that uh you can update um erc20 standard for example there are a lot of different standards I think eips uh there are a lot of

5,000 like maybe more than 5,000 eips uh I guess and we could have uh had uh onchain standards it's too late for rc20 because it's well distributed a lot of people are using rc1 and it's not really uh good for the chain itself to have onchain standards because you are enforcing them or you are just ignoring the other parts which disturbs its permissionless but other than that it makes things a lot safer and I have something to say about that so I think the permissionless part of etherium is very important for developers to anyone to be able to uh Implement anything they want that is verifiable that is that

makes sense to have on chain but I also think it's very important for and user to not actually need to know uh the blockchain is being used so you can just use blockchain to have transferable or verifiable assets or information on chain but you don't need to have the whole permissionless development uh cycle because you can just use onchain verifiable uh standards instead of using not verifiable standards like op crc2 so that's it uh so is one little um update yeah limited upgradable uh Pro standard so this is

one thing that we have been implementing in our infrastructure so geod Finance uh which I am the F co-founder of uh we have built a staking infrastructure building on top of onchain verifiable Standards uh we have built our customizable uh staking uh standard and then we have built staking pools on top of that and in the meantime we have found something called limited upgradable proxy standard which means basically in any upgradability standard you can just upgrade it if you are the owner or you can just say there's no owner and it's might become un upgradable but with limited upgradable

proxy let's say you have been using open zeppin cc20 I know I use rc2 I example a lot but I think it's very useful in that context uh you can just update your rc20 without actually disturbing its functionality so you can just say there's a new version on open Zeppelin and I want to use that because it's safer there's more functionalities and you can just upgrade it uh by just calling one function by just one click and you would have the version so basically yeah Yeah so basically onchain standards provide us a very meaningful

way to verify which standards are being used uh this is kind of different than uh other onchain standard proposals which try to uh introduct in introduce a an interface to the smart contracts instead of doing that we have a verifiable centralized smart contract infrastructure that is publishing the code and other parties uh utilizing it so yeah uh in that way we can have much more uh useful uh standards and I'm going to just give you guys uh two examples maybe four and then uh let's discuss some concerns about

this so some existing examples everyone know that in unb uh you are permission you have permission uh exchanging pools you know you can just exchange two tokens but you can also deploy one of these staking pools sorry one of these exchange pools decentralized exchange pools so you can deploy one liquidity pool for your own token and in the meantime you're actually declaring that it's very declarative I'm using un uh pricing algorithm for my token so you don't need to check every Unit web pool because they are all using the same algorithm it's bite code its code will be the same so unitap is very good

example of onchain stand standard it creates a uh liquidity standards across all the liquidity pools uh you can just Fork one of them without actually forking and you can verify that you are using Unis swap but it's actually misses one point it's not upgradeable they're introducing uh different versions uh but if you had an onchain standard it would be upgradeable like jusis safe so jesis safe is a multi platform which means uh we can have we can create a a wallet which is maintained by four people and it would be much more secure because I can lose my keys but uh let's

say we we are four friends three of them needed for the signature and that would be enough so having a mul sck is very useful but still there are some stuff to improve even with in the josu save so you are not able to just release one version and get rid of it you can improve it by having this uh little check and which means we are using the latest version uh in Genesis save and I don't need to check if it's Genesis save I can just check it's uh code verifiable uh onchain standard uh on that's provided by Junes for multi so it's that easy uh you can have a

liquidity pool standards you can have a multi standards but if those are stored in onchain uh proxies then everybody can use them utilize them and it would be actually much more permissionless while uh keeping the safety in constraints so yeah uh I think some suggestion very easy suggestion would be utilizing rc20 as an onchain standard and just making sure that everybody is fulfilling the onchain standard requirements you can distribute more like different standard too you can say erc20 d standard erc20 I don't know revising standard so there can be multiple standards but we can just

eliminate other uh smart contracts that don't that do not verifiably following this standards it's hard like it's kind of late for R 20 but we can have a do standard it's actually being uh provided by other protocols like Aragon so Aragon is a very useful tool uh you can actually verify if you have a an Aragon door that is deployed by uh other teams by utilizing the Aragon's infrastructure so it's actually useful which could be a suggestion could be um already existing I'm not sure about that but that can be something uh that is very uh important uh for doll development and finally we

are suggest we are suggesting uh on chain taking pool stand start uh which means we will be developing a staking pool and we will be putting it on on chain but we will not use it uh we will just uh distribute it upgrade it maintain it and basically just distribute the software which is a smart contract infrastructure on chain instead of just publishing it on GitHub and you will be able to verifiably upgrade your uh features and security modules without disrupting the functional to of your infrastructure at as then user uh so I think that's it yeah uh I just want to talk about

the concerns so one concern is that if everybody is using the same code and if there's a bug in that uh it makes things much more complicated for the settlement layer because we have seen a hard Fork after the doll uh exploits and this is much more likely if we convert all ERC 20s to rely on the same erc20 code that will expose a lot of tail risk to the settlement layer so it's really really important to make sure that your uh developer experience is a lot so your modules are secure and you have modules which you can actually get audited so uh instead of having all the ERC is being AED all the time which

is not the dream for for the Auditors I know that but we can just audit this one uh instance and then um get rid of the all auditing process but if we need to audit if we need to audit more we can just keep auditing the same code which would make things a lot more safer but like I said in the worst case scenario it will expose the set I cannot uh stress this enough it would expose the settlement player to enormous tail risk like uh having a monopoly on staking pools something like that it would be the same uh level of ter risk yeah so it will be nuclear if it

got hacked basically yeah I think that's it um so basically I've talked about the onchain standards which is a new Fresh look uh to the a Improvement proposals so instead of having a g repository why don't we have Improvement proposal on chain and make them verifiable that's the whole point thanks a [Applause] lot questions oh then I have a question so you mentioned saking pools so can you go a little bit deeper there yeah so right now uh you know there are some

staking pools uh which are just uh relying on one asset so you can have ether and means uh s for example or r e in rocket pool's case uh what we are doing is we are taking the staking pools and exhaust toly implemented all functionality which basically says you can build anything with any different functionality which which is around like um for example um um yield uh redistribution you can say instead of my yield that I keep on my token goes to this address I want to use

a y VA for example so we have all these functionals implemented in a library and we we are releasing that Library we are releasing the staking Library very soon so by using this staking Library you can create your own staking pool which is like creating your own liquidity pool on web by using geod Finance you can you create your own staking pool and that staking pool can be like Lio it just means use some tokens and it can be like um rocket pool for example uh you can have um modde operator bubbles Etc so networks uh the idea is that if anyone

can have the ability to stake uh without utilizing a third party by utilizing an onchain standard then we don't need to have these uh giant uh monopolies of staking pools so that's the idea um you can create your own staking pools and just start validating it by a delegation you can use a third party so you don't need to use LI or other third parties that are intermediaries between stakers and mod operators okay thank you very much other questions no then uh let's thank ice bear [Applause]

again so see you after a five minut break