EthCC 2: Craig Williams

okay okay everybody let's get the show on the road so hey my name is Craig and I'm a software developer working at curry and today I'm going to talk to you a little bit about some of the choices we've made in order to reduce the number of main net transactions that a user has to send within the calorie protocols curry platform no time for the agenda okay so Kari Daioh is a web free technical knowledge network right now we're kind of aiming to be the go-to place for people who want to learn how to build applications on top of aetherium and at the very base layer of curry there is a concept of an article and this base layer kind of acts a little bit similar to like a web 3 medium an article is free formal content it could be about anything but right now we're kind of gearing it towards fear and technical content so tutorials how to guides best practices etc etc so these articles have some requirements and one of the requirements is we want all the content to be open and free for all available all times and for that reason we hosted the content on ipfs and nothing new there we also require an article attribution to be on chains we want a article writer to be able to prove they wrote an article at a certain time on the theorem main chain this kind of helps with you can bootstrap a reputation based on their article contributions and it can help with dispute resolution if someone tried stealing your article you can prove you wrote at a certain time yeah so this was the original one kind of proof of concept that we wrote around a year ago and this is very simplified is a bunch of stuff in between here that there's no need to show but essentially a user wants to publish an article first off they upload the content ipfs it'll generate a hash based on the content and then they send a theorem transaction to this theorem a net with information by the articles such as yeah most importantly the ipfs hash of that ipfs hash is always available because it's stored in the EDM state because if you don't have that ipfs hash then there's no real way to actually obtain the content so that's kind of an important important thing well it's kind of you know we just kind of thought this was okay it's kind of a simple standard patent just kind of used throughout this base we can present this to our designer Nelson and he was kind of shocked and horrified that we enforce him that he used would have to send a transaction every time they publish or update an article the first three it's kind of like that's just web 3 that's how it is to steal it then we kind of thought about a little bit more and realized he is totally right this and reason he is right it's because transactions add a huge amount of friction to a user first start they cost ether you need to pay the gas cost which are paid in ether and if there has a monetary value so by proxy every transaction that user sends will cost the user money and this kind of paradigm shift of pain through interaction in your application is quite strange and uncomfortable to a lot of users especially users that are very new to the space and even if they are comfortable sending these transactions they also need to obtain ether which also can be quite awkward and especially for users new to the space I mean it's getting better all the time but if you have no idea what this ether stuff is you're gonna be pretty weeded out by them and even if they are comfortable sending the transactions they have ether there are times where network congestion might mean that gas costs are so high that users might actually not want to send this transaction because they think it's not worth well and in those kind of cases you get fluctuations and users and worst case scenario a user may not come back when the gas is cheaper to perform the interaction they were initially planning on performing so we added this extra requirement I guess technically is not really not really a requirement but yeah we wanted to limit the number of transactions that a user has to send when interacting with the carry platform in order to improve the user experience of the whole carry platform so I'll walk you through what some of their kind of considerate the solutions that we considered when trying to reduce the number of net transactions so the first thing we considered was the concept of batching transactions you know Backson transactions is the idea of rather than a user sending a transaction every time they publish an article instead they publish these articles and kind of off chain and these get stored in a centralized database now when they kind of feel like okay for example I've written five articles now I would like to get these articles you know I'd like to get attribution on your main chain at that point they send a single transaction rather than the five transaction they would have to assent individually and batch all the information about all those five articles together this is a probe that has been used I know at least one at one point PPE using this approach I'm not sure if they've think they might have we architected since but it was being used in the world this kind of concept of batching the one issue of action is that you only really see significant gas savings if the base transaction cost is significantly more expensive than the cost of processing each of the entities that you were batching together so I'm considering that one by just 32 value costs 20,000 gas and the base transaction is 21,000 and the only way you really see big savings using this approach is if rather than actually store in anything in a VM state you only emit an event with the information about this entity you're processing the problem with that is that smart contracts can't actually obtain any information that's been admitted in advance so you can't actually for our example you wouldn't build to prove article attribution on chain because there's no way that a smart contract naturally tainless information okay so the second thing we looked at was being that meta transactions so amount of transactions is the idea of rather than a user actually send in a transaction they will sign some information which is almost a signal of intent to send a transaction at which point third party relay will pick up the signature and send a transaction on behalf of the user yeah and there need to be some smart contract changes as well in order to provide functions that accept this signature validate the signature make sure it was signed by the correct person and then actually clear the transaction now this is cool I mean there's been quite a lot of Awesome work done in the net transaction space I think it's been quite a lot of exciting stuff done one issue with meta transactions is that someone has to pay the gas costs and usually it's one of two entities is either a third party that's external to your application that has some incentive in order to actually pay the gas on behalf of this user that incentive could be if there's some monetary value associated with this transaction they could take a small percentage of that monetary value or if there's some kind of token model in your application they could receive some tokens that makes it worth wealth and to actually send that transaction on behalf of the user but in curry we don't have either of those things I mean an article publication doesn't have any direct monetary value at least and we have no token model so when that is the case usually ends up being the application themselves that run these relays and pay the gas on behalf of the users and this this is kind of it's okay for initial onboarding phase but if you actually want to keep this going going forward it's not very sustainable especially if you want to reach kind of mass-market levels of users right you probably get bankrupted paying all these gas costs before you reach that point so it wasn't attainable fast but yet disclaimer I think there is some pretty cool stuff going on in this space cool so next we looked at a side chain so a side chain is a blotching that's independent of the theorem mean network generally it's less icky with a new theorem mean network with different proof-of-work algorithms but the flip side of that is transactions are generally a lot cheaper you have to kind of balance up right in the theorem a netbook it transfers millions of dollars every single day you have to kind of balance of do I really need that much security for my application and in a case of curry in particular I mean we're talking about an article registry so you could reason that maybe we don't require the amount of security that if your main network provides us but even if you are looking to implement a sidechain there's still a bunch of things that you need to overcome one is the user experience so you really don't want the user to know anything about this side chain you don't want the user to yeah to know it's being used at all you definitely don't want the user to have to do something weird like change the RPC URL of meta mask to the side chain address or even worse obtain some side chain tokens before they can actually transact with that side chain because that probably actually be a worse user experience than if they just had to send a transaction to the theory network right so that's one thing you to overcome make it kind of totally transparent the other is if you need to move the data from the side chain to the theorem a network need to kind of figure out an approach to actually do that bridge the two different networks just some water okay drum roll please yeah so we to go and go into the side chain and we're actually building this stuff out right now and we're not live on a side chain yet but hopefully within the next few months so we're actually deploying an article registry smart contract to the POA public network so every time an article is published in curry a transaction is sent to the POA Network which includes mention information on articles such as ID version the ITF s Hatcher is very or discussed is quite important and this is stored in the sidechain state a long way of the times down so we still have these two issues that I just explained earlier that we need to overcome so from the user experience point of view remember when I said that meta transactions aren't really sustainable and don't really scale only through your main network this isn't actually the case anymore on a site chain because transactions significantly so much cheaper than the theorem a net is actually a more reasonable approach to actually go forward and pay a users gas costs only fact it's actually a lesson one cent per block to fill an entire block right now on a PA network so yeah insanely cheaper than if your main network so calorie are planning on running some meta transaction relays ourselves in order to pay the sidechain gas costs for a user and yes this is how it works so it looks a little bit again very simplified a user uploads their content ipfs they then sign some information about the article data they want to publish and then they send that signature along with the article information to the meta transaction relia at which point the Metro action relay will send a transaction to the PA network on behalf of the user and the user never has to know anything about the P way network they don't have to know it exists they don't have to send a transaction they still will see a mask Popat right now because they need to sign some information but we're hoping to eventually be able to remove that as well and you could say okay so if you're running your own your own relay is it's kind of a single point of failure and you're absolutely right it is a single point of failure we have this kind of split in the calorie M application between the protocol layer and the application layer we kind of consider the application layer as a bunch of services that kind of enhance the user experience for a user and can provide some services that makes their life easier when interacting with the Kauri protocol but the protocol layer itself is decentralized so if the application layer went down okay they couldn't send transactions via our UI right at that point but if they still wanted to publish an article they could still send a transaction directly to the p/y neighbor themselves and pin the data type EFS in order to publish an article so this is kind of a balance that we can help you with right now in order to make our application feel like a real application you ever seen that we are this is a iterative thing so we are you know we probably will look into using third party relays in the future to kind of decentralize that a little bit more so the second tricky part inside chains is moving from the side chain to the main chain so remember we want on chain article attribution and now all our articles will be published to the PIO a side chain so we need to be able to get partial attribution on the main chain even though all the content is elsewhere so we looked into plasma and plasma cash I'm not going to give a deep dive into plasma because I'm sure there's plenty of other people in this conference with more experience and more qualified to do that than me but I will give you a quick overview of what plasma is all about so plasma and plasma cash are specifications that allow a user to move assets securely from the main chain to a side chain back from the side chain for managing plasma cash in particular is geared towards NF T's and you could imagine that an article within the calorie protocol could be modeled as a 10 ft if you wanted so in plasma there's a concept of an operator and that operators job is to bundle all the transactions that have yet to be committed to the theorem engine and create a miracle tree of those transactions and then publish the Merkle route to the theorem a network at which point if a user wants to exit from the theorem say chained to the main chain they need to provide a Merkel proof to the theorem main Network contract that basically says okay there is a transaction within this Merkel route but where I received this asset and I want to exit with that asset that's not the end of the story because just because a user received an asset at a certain time it doesn't mean that they now own that asset right they could have transferred it on since so there's a concept of a challenge period and that challenge period is this so that if a malicious actor who once owned an asset tries to exit with it they can provide a valid miracle proof that says that you know there's a transaction within this Milka route where I received that asset but they may have transferred on since so the challenge period is there so that a the rightful owner of that asset can spot that this malicious exit is occurring and they can send a challenge to that exit to the theorem in contract and they can say okay sure you did we see this asset at some point in time but I've received its assets since in a later block than the asset when you receive this asset at the toe you then the yeah so this is it's proven that I receive this asset after you therefore you don't own it anymore and that's why the challenge period is a so it's bunch of usability considerations in plasma the particular one for us is this challenge period it didn't feel like a very good user experience or something we risk have thought was acceptable for us for user to publish an article and then potentially have to wait one or two weeks before they could prove article authorship on the theorem main chain in order to do something like play the bounty that was fulfilled with its article it just didn't feel like something that would work for us trying to explain to the users why this challenge period exists just wouldn't work so we kind of started looking at plans a little bit more and we realized that a lot of the complexity of plasma is down to the fact that it's assumed that assets can be transferred on your theorem ops ion saging step transferred on the saging so we kind of thought what if we enforced it articles couldn't actually be transferred on the say chain at all and once they are published on the side chain there only never changes the duration of their lifetime on that side check I'm not saying that's kind of the behavior we want it anyway and we realized that with this kind of caveat with this restriction that it takes away many of the usability issues of plasma and you can actually remove the challenge period entirely because if you can provide a medical proof to say that I own this article within a certain local route that means that you open it indefinitely assuming that that can't be transferred on the etherion sidechain so it turns out we can actually remove the challenge period entirely so that we kind of stumble on this concept of checkpointing and we have a concept of a check pointer and the check pointer is very similar to a plasma operator this job is to bundle up all the articles on the side chain that if you had to be committed to this theorem a network critter mikkel tree and then published that local root onto theorem a network very very similar to how a plasma operator works and then on chain article attribution can be achieved by simply generating a miracle proof that proves that there's an article within a certain checkpoint to move a route that I own and like I said before because these articles can't be transferred you don't need a challenge creed anymore you can kind of if you have a proof that proves you own it and you definitely do own it on the side chain so that makes our life a lot easier this is how it works under the hood kind of explained a lot of this already so yeah the checkpoint pulls in all the name non check pointed articles from the POS idream generates a nickel tree a whip point at which point it generates and pins this concept of a checkpoint document to a PFS this checkpoint document is a very important document I'm going to discuss it in the next slide explain what that's all about once it's generated that it and signs the checkpoint document hash along with the merkel root of the nickel tree that it generated from the articles with its private key so the check pointer has a well-known public address or a list of public addresses so it signs this information with his private key I wish point the check point it can send a transaction with all this checkpoint information including its signature this signature is this so that it doesn't necessarily have to be the check point of its sends this transaction it can be a third party as long as they receive this information from the check point in it and if we prove that the check point to actually sign this information it's not necessary the check point of it has to actually send a transaction because this signature is validated in the smart contracts yes this checkpoint document that I mentioned it's a very important document and it includes basically all the information about an article that will be required sorry all information about a checkpoint that would be required to regenerate the Merkle tree of that checkpoint so all information about all the articles an article content is included with isn't within this checkpoint document and it's important because if you can't access this checkpoint document you have no idea about the articles that are included within that checkpoint and therefore you can't actually regenerate the miracle tree and because of that you can't actually create an article proof from that miracle tree so it's required for article attribution for that reason we're going to store it in multiple places so we're going to pin on multiple ipfs nodes and we're going to store it in our own centralized series as the backup as well and we're also going to provide a way for a user to download their checkpoint documents so that they're relevant checkpoint documents and as long as they keep those safe they'll be guaranteed to be able to prove article attribution on chain whenever they want they haven't got to rely on the ipfs knows pin in the data etc okay so there are two ways that a checkpoint can be triggered and I've kind of alluded to both of them a little bit so one is automated so the checkpoint of them cells send in a transaction and the reason why we want to do that is because article proofs are kind of dependent on the checkpoint of service itself until the checkpoint of service has committed a checkpoint that includes that article so we kind of want to provide guarantees to a user between the publication of an article on the side chain and being able to prove article attribution on the theorem main Network to get that security of the theorem a network and the other way that a checkpoint can be triggered is manually so in our calorie UI we will have some indicator that indicates the state of an article whether article has been included within the checkpoint on your theorem a network or not if not they can click a button which will call our checkpoint service and will generate a checkpoint at Avvo described besides the point the point of actually saved in a transaction so the chat pointer will it will generate the local tree publish the checkpoint document but then able to return all this information back to the user and then the user themselves can send this transaction to manually checkpoint their article onto theorem a network and the cool thing about this is a so cool like foot and Boulder the bottom of the slides is that because it costs the same amount of gas regardless of how many articles are included within a track point because we we only store one bites that you to value which is the local root of that checkpoint it means that anytime I use the decides to checkpoint their individual article it will actually checkpoint every other article in the system that has yet to be checked pointed as well so you may not have to wait the twenty or four hours for the automated checkpoint in your article could get checked pointed because it's been bundled within a checkpoint that someone else initialized I think that's pretty cool yeah so one last thing on this I thought it's worth bringing up but there is some kind of inherent trust in the checkpoint err a check finder could lie about article authorship they could even change the content and this can actually be proven on chain but all the data that the checkpoint consumes and outputs actually is all transparent and open so even though it can't be proven on chain it can be proven off ting so you have to think what are what are the incentives for a check pointer to act maliciously I kind of like comparing about the plasma again plasma has the concept of a exit where a user is guaranteed to be able to exit with their funds if the plasma operator acts maliciously and so I kind of think comparing it to our next table I can carry considering we don't actually have any monetary value on this side chain I consider it exiting carry to look a little bit like a user so if a checkpoint acted maliciously I usually could easily spot it off chain they would just remove all their articles from carry they would just pull them off and put them somewhere else and they would probably never use carry again they would probably posted on Reddit and Twitter etc so this really not much of an incentive considering we are the ones running these checkpoint us there isn't much incentive us to act nicely and if we did it could be publicly outed and it would just be a disaster for us so I think the in st. is are quite well aligned right now a low in the future we are considering utilizing Oracle's to essentially this further but again it's it's kind of iterative process right so yeah hopefully this will come over time yeah so in summary transactions are a huge area of friction within your DAP and there are lots of different approaches one solution doesn't fit all or works for one application might not work for another make transactions a lot more sustainable on a side chain and yeah by enforcing that assets can't be transferred on a side chain it makes exiting from a side chain to the theorem main chain quite a lot easier yeah and one last thing I would say is and any back-end developers in the room its to kind of concentrate and consider UX when architecting your systems because I feel like the theorem space it's unusual in that but the back end developers are so close to the user experience like I'm commonly a back-end developer I never thought I probably mentioned user experience in a talk ever but if this whole like transaction is such a big friction point in an application and it's dominantly a back-end thing to just think about those kind of things when you build new systems cool that's all thank you very much [Applause] didn't have any questions cool all right thank you much