Composability Extreminists: Callback or No-Callbacks? / Miao ZhiCheng

Transcript

foreign having fun staying pure today yeah I really like this place and uh it's this means a lot to me the power Landing Police and the East parag and that's where we actually started uh the Inception of the super fluid so today we're going to talk about the callback or no callbacks so I'm nowadays I spend a lot of time for super fluid

and uh super fluid is a money composable money that can do streaming and mass distribution right so composability means a lot to us in fact I would say we are a composability extremities so we go extreme right so I'll show you what do I mean so what do we have got today here so how many people here knows about erc's triple seven all right some um so it can be a good idea so that a single transaction can do both send and extra action right what otherwise uh

I'll talk about otherwise how we do it but with single transaction you basically send the token to a contract and contract can Implement some actions right so that's a good idea but there's also bad idea part of it so the change in the semantic of erc20 transfer in the car in the actual standard so they added extra semantic to that dot transfer so what what happened right the first units of V1 hack right a lot of money got trained now pretty nowadays seems a very small amount but yeah that was big amount before so and also the same thing happened to landf dot me right so uh a similar thing uh the reality is that uh there are not

many ERC a triple seven token out there in fact super fluid token are the only ones and that's the reality so in order to do a uh action uh together you have to do the approve and the transfer from right you you I think I think many of us here hate it that you have to approve a contract and you have to do action right so that's not nice so but in order to fix one of the bad ideas from the triple seven standard we create some little bit of dialect so our token uh variations we actually disabled that ERC triple seven dot transfer semantic that is uh so we just make the

erc77.send have the Callback right so in fact super token comes with more callbacks so before I go there's actually a very good uh genealogy tree uh study of the the the es20 right more detail you can find from our mono wrapper wiki page a page called about ERC triple seven kudos to our colleague DD so what are the new callbacks we added to Super token so we're talking about something called agreement life cycle event hooks so first give a quick overview what is

agreement so in super fluid you know because we are composable money that the that supports money streaming and distributions so we have to represent relations between accounts and their ongoing relations so if I send you a stream of money and that relation is ongoing until a Time ends or I delete the flow or or the outside delete the flow right so there's ongoing relationship between the accounts and the way to calculate how much uh balance you have of your account is to aggregate all those agreements and their balance amount in JavaScript would

be like a reduce all the balance provided by that by uh by by a list of agreements and sum it up in the end right so the implemented agreements in our case uh the first one I talk about money streaming that's the most common uh most popular one that's the constant flow agreement so it's streaming money every second oh sorry every block uh we call it every second but every block to from one account to the other to one two one but we also have a distribution right so it's called instant distribution so it's got kind of money fan out way of uh magnified on stocks on steroids right so the money distribute from one sender to

any number of subscribers to like the uh to to that uh index we'll call it so there are all things we can introduce in this agreement framework uh in fact erc20 can be considered and just agreement normal agreement so your balance from your studies can be fit into the agreement framework we also have some experiment regarding decaying flow like the radioactive decaying right so every um every uh there's a half-life so if you say that decaying period is one year then a half after half year the flow rates become half and half and another three months the flow rate become

another half right so there's a decaying type of flow we can Implement instead of the as opposed to the constant flow um we also have a combination of the instant distribution agreement plus the constant flow agreement combined into something called a General Distribution agreement so that imagine that instead of sending a dividends to 10 000 accounts I'm sending a stream of new type of dividends that goes to 10 000 accounts every block right so that's a new thing we can also build into the agreement so that's a agreement in nutshell so there's life cycle events for this

ongoing agreement or ongoing relations between accounts right so let's use a CFA the constant flow agreement as example when you send a when you send flow a stream of money to another account so that's when the agreement is created so there's a before and after hook uh callback right but when you update the amount let's say you were sending to ten dollar per month then you update to 12 per month there's update there's also events there right but when you delete that flow there's a another event called agreement terminated so there are various type of callbacks we are talking

about here it's got a life cycle events so here's now we can become a composability extremist right so we have something called a super app so it is uh ongen contract that implemented the agreement lifecycle hooks so all those hooks in previous slides I mentioned you can implement the the function to handle them right it enables Atomic and transactional composable agreements right let's see a couple of a simple example so the first uh a super app example is a DCA a dollar cost average so the idea is that many want to invest

every day some usdc for BTC for example right so the way it's implemented is that um when Bob stream usdc to the screen box in the center the super app called DCA super app and it triggers a callback and it will trigger the Callback that gives uh calculate how much Bob should get distributions or in an ongoing basis so in the blue box it's it's exchange so the DCA actually can go to The Exchange periodically to convert some of the usdc for BTC and the agent is the off-chain

component that actually triggers this constant a periodical uh job right and then Bob or Alice who invested in this DCA super app will then get periodically distribution of w the rapid BTC simply by sending the stream of usdc to the green super app right the super app also needs to handle handling life cycle events why because if Bob stops the stream then Bob should also stop receiving Raptor BTC so as simple as that without the life cycle events handling then the app can be in danger of sending too much

it needs to send to the send back to the Barbara so there's a kind of accounting accuracy here it's enabled by the the this new type of applications powered by the callbacks another example it's a referral link app right so uh there are three parties actors in this space so there is the merchant and there's marketer uh for the merchant and there's a buyer so the buyer send a stream for money for to buy a service for a merchant through a link that is shared by the marketer right then marketer automatically get a certain percentage let's say 10 of a

commission so long as that ongoing purchase from the buyer to the merchant is ongoing right so that kind of atomic composer stream enable this kind of scenario that marketer get a commission so long as the purchase is ongoing so that's a super powerful thing enabled by the callbacks again right so what are the problems though right first callbacks are scary all right callbacks can reintroduce can introduce a re-entrance issue everyone see quite often from time there's a re-entrance hack and a couple million gone here and they arrive so it's scary but not necessarily scary right so if you do it right so in addition the bad design can can be a a breaking chance to the uh the for the example is the erc77

transfer right so it's uh it can introduce back uh bad design also and the list of evm related exploits that are related to the reentions issue is a lot right so it's scary in short so the the solutions to the Callback problem right the first is not really a solution is just to avoid it I think that's many projects go with that just don't have it right but to to actually make it better there's a you can apply the idiomatic programming pattern so be more careful when you do the programming right so the check effects uh interaction is a common pattern right uh re-entrance lock is an is another hedge Hammer that you can solve this problem

to purchase by having a mutex and avoid the reactions altogether um not related to evm but in other account model like utxo they can also they solve it differently because they limited side effects are but I'm not going in detail where any stem conference here um one of the problems I didn't mention though in the pre when I talk about the super app is that we need to give a exit guarantee why think about it if you send a stream to a super app and super app has a callback to handling the termination but if what if the super app refused to close your stream you're kind of keep

sending to the app and app refuse to close your stream you are losing money forever right so in in the super fluid system we need to give such guarantee that the app should never be allowed to do that so if you want to end the ongoing relations the stream of money it should always be allowed to do so so that's the problem and we have a very peculiar system called a Geo system so if the app violating that the exit guarantee the app would be marked as something criminal right so it's it's most likely faulty right so it should be marked like that so that should be stop functioning so that's how we give the exit guarantee for the for the agreement

so but let's look back so let's slow down a little bit so let's looking back what is actually the composability before we analyze bit more um so if you look if you go to Google and search if you go to a search engine or search uh what do people say about the composibility you actually a lot of web3 links pop up well weptoring industry uh web links a pop-up I was wondering if it's because my search engine was biased and I think I disabled cookie went to private tab actually a lot of linkers from web3 people so I think we are contributing a lot to the internet right so uh it's it's not a bad thing because course web3 I guess so there's a research from multicoin the research

from uh Aragon there are things from uh future.com that people say a lot of about about composibility a lot so you can search and find these links and you can have a read about them um so but in the in the in the in the other world the non-web three World there are already established definition actually for a long time about the interoperability model right so this is one of the conceptual model it looks very similar to the network model if you're familiar with the OSI model right so there's a the lowest level would be no interoperability the first level would be technically the it's called integratability then the next level will

be interoperability the next level be composability all right this is all abstract if you're interested you can search about uh it's called a conceptual interability model let's wrap that to uh ethereum world what does it mean so the layer One Technical and Layer Two syntactical integratability reflects to this instrument we'll use from evm right so the the evm op codes of codes that is for interacting with the ethereum contracts right so you have a static core for read read only view course you have a delegate call for letting other code managers manage the call as a storage then you have the actual core for the internal

transactions that those are the technical instruments you could use for composability in evm level and evm also transaction also is automatically rollback which is a feature you will use a lot in the in super fluid right because if it doesn't roll back then you can't have Atomic Atomic transactions so that's the lowest level then the next level would be semantic level and the pragmatic level uh program program programmable level so there is usually we rely on the a solidity API contract specification but the attention is many people tend to forget that you don't need to send all the all the messages you're using a solid API specification actually

you can you can you can send some even under the radar transactions that the baby is block scanner wouldn't be able to even decode it right because you can totally bypass the the API decoder and there might be even well I don't think they have but there could be right the code of bug from sorry the contract API a solidity decoder right so that's just some some attention that uh it's it's good to remind yourself when you look at this kind of layered approach through this layered approach the last bit interesting part will be the composibility you have the dynamic and conceptual right so how do you achieve that first write your code very modular right distribute your uh through the the open source uh ethical verify the source

code then people can start to compose with your contracts and better to be autonomous also permissionless so that you don't need uh other people don't need your permission into interact with your system and discoverable right provide example code is just the basic way of make it discoverable but maybe we can also borrow something from the web 3.0 the one before like what if we can self-document to the contracts and then it can be discovered automatically by other contracts to do the interaction right so uh it's just a suggestion maybe you can think more about it so a couple of patterns an example like let me go quickly um so one important method to make your system composable by

others is to adopt existing standards right so es20 is best example it has a vast ecosystem right it has a wallet supporting it a D5 supporting it right units open Support also so we have to 20 tokens then you have block scanner supports it natively yeah C20 so by adopting those established standards You Are composable by others and triple seven is actually offset example it is a standard but it has no option I mean we made a mistake to use it but we are the only one actually using it things like 2771 is a good way to make your contractors to support uh Native meta transactions for example right

that's basically padding The Message Center in the in the code in the hidden core data as plugging approach is another one to be composable right so Ada is one of the our baby projects uh before super fluid we have also something called strategy way before yearn has a strategy but we only implemented a compound strategy unfortunately but the joint has like 250 strategy or something that I just lately checked right so that's plugging quote quote plugging super fluid agreement is another type of plugin where adding more features without breaking the interface per se right transactional system is uh where the Callback coming from right or the all our super apps are using the transactional concepts right so if

something happens something else should happen also if one fails it should revert flash along is not the type of transactional system if you can make a profit finished transaction if not revert everything right so uh conceptual system it's going even deeper right so you have to have different components they work together become an even more conceptual level of composibility all right I think I'm running out of time so I'm not going to go through how we actually did our control flows um I'm gonna go just talk about the last conclusion so my conclusion would be composibility is powerful and worth

efforts right callbacks are powerful and it's worth effort and it's not new problem I think I would encourage everyone look into the uh existing uh in other other kind of non-non crypto industry how the history evolves regarding uh composibility learn from them and it's not a new problem we can draw insights from the past and and there's more than one way to achieve composibility so that's my conclusion today and thank you so if you want to know more about it and want to be part of it join super fluid of course and we have a park bounty on immunify if you want to check our contracts and maybe help us to improve the security

start hacking superflu mining go to our monorepo superflu finance Dash slash protocol monorepo and the presentation source code it's also available now on our Wiki page so thank you very much thank you thank you very much meow just anyone have any questions from the audience ah we have one question we have time for one wait for the jingle to finish of that contract

yeah so once the contract is jailed that kind of internal accounting of that country is no longer guaranteed right so yeah that's a simple answer okay the the jail thing is that like something that's automatically like you can detect if a withdrawal fails or is it something that requires like governance or manual intervention to like jail a contract so that there's a couple of rules to determine if the app should be jailed if that's what you're asking so the the jail Roo are very black and white it's all in the small contract so if you if the basic one review revert in the Callback in the termination it got jailed or if you're if in the if you run

out of money as an app you also got jailed and there are a small list of uh rules that automatically trigger the jail condition then the app basically got broken yeah