Moving from MVC to SACI - a development framework for modern DApps

Transcript

foreign hey good morning folks um small audience but I think uh we can still go um today we're going to be talking about sassy sassy is a framework for uh building decentralized applications that are actually decentralized um quickly about myself I am madhavan I am one of the co-founders of quest book you can find us at questbook.xyz um so uh what I'm going to be really talking about today is how we should be building decentralized applications um and some of the learnings that I've had uh while building Quest book so I'm going to shamelessly use Quest book as a uh setting the context for um what we're going to be talking about today

so um quickly about Quest book so Quest book is a tool to run your entire grants program so protocols run their entire grants program using Quest book um completely on chain uh what that means is this protocol for example polygon ocean protocol perp uh all of them are using Quest book uh to disperse hundreds of thousands of dollars every week and they do not have to trust us even though we are only like what three or four months in uh they don't need to trust us they don't need to believe that we are going to be around forever for them to be able to use our product um uh without any without any hassles so uh the reason that I believe that they trust us with all the money is because our product is completely decentralized

in the sense that even if you want to steal money we can't right and that is verifiable uh in the code and that's what I'm going to be talking to you about today all the decentralized applications that we see out there uh should have this property and that is something that I believe a lot of developers in the ecosystem are not adhering to I did a small research it's published on my blog uh you can check it out later but um the the core understanding there is most of the developers are writing web 2 code in solidity that's that's kind of like worst of Both Worlds right so you're writing code in solidity which means that uh you have all the inefficiencies around the transaction speed the transaction cost and the limitations of the evm itself but at the

same time you're not even hardnessing the uh benefits that web3 gives you or solidity gives you uh so it's it's just like the the worst of Both Worlds uh and today I'm going to be talking to you about most of the mistakes that people are making something that I've been seeing across various code bases um so the first problem that I see is uh people are not adhering to trustlessness uh I know we keep hearing these terms uh over and over again but today I'm going to be talking to you about uh specifics of the mistakes that I see people uh making in code uh so what does trustlessness even mean uh is if you ask yourself the question hey does this app assume that there needs to be an honest actor who is running this entire app and

can they pull the plug on you on on the user I think that's a question that all of us should be asking and I'll show you an example of where trustlessness is uh kind of not adhere to so here's an example of an nft project that had about four to five million dollars of uh transaction volume and they had this little line in their uh smart contract which says uh remove nft token so what this really means is even though it says only the owner can um remove an nft it assumes that the owner is not going to do bad things it assumes that the owner will not fraudulently take away the nfts from a particular user so I think this is a

major anti-pattern that we see over and over again I think only owner as a keyword is a really uh useful Library by open Zeppelin but I think it's massively misused in in such scenarios where uh it's being used to just override some of the um you know features in the in the product itself so this is not trustless right so this is not trustless because it you have to trust the owner over here to not uh fraudulently um revoke your nft tokens the second thing I want to talk about is censorship resistance again uh this is closely related to uh trustlessness but in the sense that um can you can someone ban a particular

user from using the product because of subjective reasons right so it is okay to ban a user as long as the rules for Banning a user is encoded into the smart contract itself but if it is dependent on a subjective judgment uh I think that's that's really bad and I see a lot of uh projects using uh not not adhering to uh censorship resistance and here's an example uh we've all also probably used this um keyword called possible so possible is another library that I feel is misused a lot it's a very handy Tool uh don't get me wrong uh posable is a great tool for um making sure that the initial iterations of the product uh do not have

any security bugs and stuff like that so it's a it's a useful tool in the early days but the reason I pick on this particular code snippet over here is this is a project that's been live for more than three years um and it's a contract that has been having a volume since the last three years which I believe is a long enough time to Iron out all of the bugs and make sure that the uh there are no upgrades required anymore so I think possible over here is is an anti-pattern again um just to give you an example right so let's say this is an nft project and if you're seeing some kind of activity happening on the Discord Channel where there's a whale that's going to come and scoop in uh some of these nfts you the owner over here can go and pass the

um pause the contract and um you know basically uh censor all of the transactions that are happening during that time last thing that I want to talk to uh you about is permissionlessness again the question to ask is uh can other people or contracts use your product without having uh without needing the permission of the person who has deployed the contract um again an example over here uh this is a quote snippet that I picked up from one of the projects that required a particular function to be called um on a regular Cadence so this is a there's a script in the same GitHub repository that um that that's run every week and now that assumes that the person who's going

to be running the script is going to be the same uh the same person and now let's say that person uh decides to discontinue the project and stops running the script every week uh there's nobody else in the community who can come and take over right so the only way for somebody else to come in and take over is if the owner of the project transfers the address of the variable over here that you see platform uh to a particular person without that permission of the owner um nobody can take over the uh operations on this particular project so I think it's it's very very permissioned uh and it it relies on the trust that um the person who's deployed this contract is always going to be active and maintaining this project

uh now that we've seen what we should not be doing I want to quickly talk to you about what we should be doing and I want to introduce you to a framework called sassy uh which is a replacement for MVC MVC in the web tool uh sassy in the web 3 world is what I believe uh of course going over the uh four terms in the in the acronym sassy uh so the first thing is storage so uh I think all of the data should be stored on uh stuff like ipfs RV filecoin whatever uh but not on something like a MySQL or a mongodb that is because um if if you are storing data on MySQL uh a it's not not trustless because well you could shut down the system anytime

it's not censorship resistant because um well you could just use the command line to delete a particular user and third is not permissionless nobody else can take over the responsibility of running the MySQL server from you uh if you decide to shut down so um this all the data should be stored I know um ipfs file RV are all um blob stores in the sense that you cannot uh have a have a schema around the data and that's kind of okay we'll look at how to make the data queryable a little later but I think uh broadly we should be storing all of the data permanently and stuff like ipfs RV so that even if you decide to shut down your uh product it can still continue to run on the same data that was uh

generated before you decided to shut down the second is um the app itself um I think the app should be a progressive web app or a single page web app which means that the entire code or the entire logic is always running on the clan side um not only that um so I do recommend that we use uh react and HTML5 to make the app itself all the UI related business logic should be on the front end and the uh app itself should be bundled and stored on ipfs and served via ipfs again so that even if you decide to shut down the product um the app is always still accessible uh

via ipfs we've already talked about uh contracts so I'll quickly uh go over it um I think all the critical business logic especially those around ownership and finance uh should be encoded in the smart contract itself so if you notice the difference between MVC and Sassy here is that the logic that went into the controller in an MVC should now be distributed between the smart contract where your core business logic goes around ownership and finance and the UI business logic uh should reside completely on the app on the client side so there's no no server that is actually serving all this data so again you should be

um doing these not doing that right uh and finally I think this is this is the um uh Secret Sauce in The Sassy uh framework that is the indexer indexer is something like a graph protocol and this is what brings all of the other three pieces uh together in one place so the way that uh you should design your product is um store the data on ipfs um emit that hash from a smart contract and when the transaction is completed the ipfs hash gets emitted that emission is caught by um the the graph protocol and then is able to index it what I mean by indexing is also the fact that the blob store that is there on ipfs will come get

converted into something that's more schematized right so you can make the data more queryable and usable across your entire product uh and in summary uh what we should be looking at is uh building a Loosely coupled product without any trust assumptions uh using the sassy uh framework where I think what is now uh beginning to become irrelevant is the uh MVC framework in which there are a lot of trust assumptions uh I think abroadly is a bad idea while you're building an app that's supposed to be decentralized um that's about it uh finally I think that's a bonus for people in the audience or people watching online is

um if there's somebody who is willing to build uh an equivalent of Ruby on Rails for sassy you know Ruby on Rails is for MVC uh sassy is a new framework if somebody is willing to build the application framework for that we're giving out a grant for five thousand dollars um in HCC and if uh you're building it here's the link that you can visit and get more details on how to get the grant for five thousand dollars thank you foreign [Applause] any questions not today

thank you [Applause]