Etherisc, Golem and Ethanos Sessions (Combined Recording)

Transcript

[Music] do [Music] hello this is christoph muschenrock of etherisk

i'm very grateful to be part of etcon 2020 we founded etherisc in 2016 and in the past four years we spent a lot of time to explore the regulatory frameworks for blockchain based insurance and it was very hard and many time times we thought it's impossible to fulfill the regulatory requirements but today i want to show you a new promising legal model for blockchain based insurance it's a genuine new approach and it works only with blockchain so we think this is a very natural and typical application of blockchain technology to the financial industry

but let me tell you the whole story from the beginning two years ago we called the german financial authority barfin hello this is easy risk we want to build an insurance business they told us ok the only thing you need is 5 million euros we said we don't have that much money aren't there any exceptions but they simply said no no exceptions this year we called again and let me explain what happened in between

insurance is highly regulated in most countries usually insurance is a legal promise to pay a compensation in case of a loss luckily germany has a formal definition for this but it is very similar in other countries as well for example in the us the legal promise to pay in case of a loss is a root cause for a pile of regulations and the reason for high minimal capital requirements and these are usually in the millions creating a high entrance barrier for new market participants

and disruptive products like ours but why don't do we need all of this regulations have been created for good reasons regulations have three main objectives to avoid monopolies to avoid negative externalities so negative effects on third parties and to avoid information asymmetries these objectives shall mitigate unfair and unethical behavior on market of market participants and they shall stability stabilize the market

consumers need to be protected if someone promises you something you should get what you expect and consumers need legal guarantees so they can sue the company and the same applies for investors and you need legal enforcement because regulators need effective measures all of this shall create trust between market participants be it consumers invest stores or producers but in many cases trust by regulation can be very expensive

and people can build trust by other means especially for retail products legal enforcement is pointless due to time and cost of enforcement for many retail products we don't need and want legal enforcement instead simple market mechanisms provide much better consumer protection think of a vending machine if the machine doesn't work you won't sue the owner it is in his own interest that the machine is working properly and otherwise he'll lose his customers but how can customers trust an insurance

product without legal enforcement the answer is smart contracts smart contracts provides a means to ensure proper and transparent execution gives the consumer a bulletproof insurance product based on smart contracts and she won't need a legal guarantee replace legal guarantees by technical guarantees everybody can check and let's see how this could work in practice maybe you remember this is our flight delay insurance select the flight and then pay the premium

and finally you are informed that you don't get a legal guarantee for your payout that's it your policy is processed by a smart contract and you can check the proper processing directly by examining the code and the transaction if the code is correct your policy will be processed correctly and the provider won't be able to mess with it what's the consequence we explicitly exclude any legal guarantees for a payout in case of a loss and therefore one crucial element of an insurance contract is missing

and therefore this is not an insurance contract according to german law and if it's not an insurance contract then there is no regulation if there is no regulation then you don't have regulatory costs and you don't have 5 million euros minimum capital of course consumers need to be well informed that they don't get a legal guarantee so this year we called the german regulator laughing again we explained our concept and asked hey if you exclude a legal guarantee will it still be an insurance contract

and barfin said no it won't be an insurance contract and we asked if we offer such a product then we are not subject to the whole pile of regulations and the answer was yes indeed no regulation no minimum capital requirements no 5 million euros needed anymore we can start our business with much lower capital and so currently we are working on an implementation of this model and we also think that this could be the blueprint of a whole class of innovative insurance products but beware there is no

insurance contract and therefore we may not call it insurance because this would be misleading instead we use the term protection and you don't pay a premium but instead a service fee because what we actually do we offer only the service to run a set of smart contracts so say stay tuned thank you for watching and goodbye [Music]

this [Music] [Applause] [Music] nice

[Music] [Applause] [Music] [Applause] [Music] sorry wow [Music]

[Applause] [Music] [Applause] so [Music] so [Music] so

[Music] so

[Music] [Applause] [Music]

[Applause] [Music] [Applause] well this is going to be fun i must admit this is my first pandemic conference i'm so glad i have a standing desk here so i can be walking and hand gesturing sorry if it bothers you too much in a in a remote setup this is how i roll when i'm presenting to people anyway hi again i'm kuba kwarski

i'm chief product officer at golem and i'll be talking today about where golem is and where we're going with this thing and probably the best way would be to start with showing you uh this slide about our history um so uh two things that are important here first uh we are old crypto wise we started early we are pretty terrible so we had a lot of iterations already a lot of lessons learned and our last release is clay golem and

we actually uh helped developing a use case recently called called kamet golem and it performs simulations of of chemical reactions that are forming a network and this later is being used in a health industry to develop new medicines and we're very excited about this because this brings us closer to one of our goals to to being a platform like a public good platform and we will be porting uh this use case to to new golem but for now this is on on legacy and this kind of gets us to uh to the token migration thing uh

you might be aware or not uh our token gnt is not your c20 compatible this is because we we are an old project again and uh your c20 token was still being discussed at the time i was like not obvious to to use it uh when that when the contract was being created and this is something we definitely want to change so that talk and migration is coming and you will be able to migrate your tokens to uh to to new token and there are multiple reasons we're doing this but probably the most important ones are our fee feature reasons so we need things like gasless transactions

uh layer 2 scaling solutions support for smart contract wallets these are all the things that comes with erc20 and and and this is why we're migrating and so what golem is um golem is this completely new set of protocols and they all come together to create this platform for for for resource sharing and this means like discovery matching uh selling buying i mean all possible types of of computing resources you can think cpu gpu

storage network but also think about things like unique hardware so let's say you have a telescope and you want to monetize your telescope by sharing it with other people you could be doing this with colin this is how extendable the the protocol is and of course because this is new architecture it is also a completely new code base and and the new code base that is written in in rust uh i wanted to show you a slide about architecture just one slide with the with the architecture of new golem uh and i want you to remember two things from this slide first there are two types of of nodes in golem network requesters

and providers and the second thing is all the boxes that you see on this on this slide are interchangeable this is how modular and open the system is and and this is not just a theory this is something that we're doing right now for some time we have like a centralized implementation of our marketplace and now we have a decentralized implementation and we're plugging this into new golem and this is just a feature flag this is this is how easy it is so how are we building this of course we go and we are defining these protocols we are writing our own implementation of these protocols however

we're working like very closely with developer community every step of the way getting feedback doing surveys demos private feedback sessions uh and we will continue to do so and uh we actually called new golem like a uh developer oriented golem because this focus on developer experience is uh is something of a great importance for us and we're constantly thinking what is missing what are the obstacles from the point of view of the developer what can we remove

what kind of design patterns are are there that we should deliver what kind of usage patterns we should deliver what is the the lightest possible development environment that will allow you to start tinkering with golem how to make the the learning curve as shallow as possible actually let me share a slide with you this is uh this is uh python code using using new goal and platform and using our experimental high level api for for a new golem and this is that simple you just define what your worker should be doing in this case rendering one

frame in blender and then in the other section you're defining uh how to split your task in general like in this case into uh into sending multiple frames to to multiple providers and that's it uh there's one more thing that is actually very interesting here uh on top of this slide you will see like image hash this is actually linking to the to the image uh this image has been converted just by using our our command line tool from like a plain docker hub image so uh you just need to make sure that that that the image is uh

the image allows to to to run your code and that's it uh the the define the the definition of of the memory and storage here is it's actually optional but but you can define it here too uh if you're a developer and this is still rocket science to you then i don't know what to say to you uh no actually scratch that uh we will make it even simpler we'll be working on making this even simpler i think we're kind of in a good place already but for some use cases for some usage patterns

we can make it even simpler right imagine like a just using a python decorator to to type the functions that you want to execute on golem um now the second thing that that i wanted to talk to you is payments because payments often introduce introduce a lot of friction and probably uh previous speakers at the conference already mentioned a lot transaction costs so i don't need to dive into this uh golem has never required you and new golem will never require you to execute costly smart contract interactions just

to perform things like discovery matching and agreements this is all happening in our marketplace so all you have to do is you know just pay for the pay for the work and these are just like simple erc20 transfers and we know this is much cheaper than uh this is much cheaper than uh smart contract operations but on top of that like our priority is to deliver like a layer two driver for for for payment module and uh yeah so like it will be no crazy overhead on on performing

uh performing operations on golem it will be a non-issue general um okay so sometime in april uh vitalik tweeted something like this and he tweeted about mechanism design punk and then someone replied with that with the name system punk and i actually read it one day later and for me this was like 4 20 so my mind exploded you know how magnificent this system punk name is i love it and yeah but jokes aside uh i actually think that this is what we're building here uh this

sturdy say building material that you need to build system bank applications so i'm not saying you know don't build the legacy thing don't build things that we allow scientists or enterprises to scale their computations please do build them this is a valid use case for golem but think what kind of applications would really benefit from values like censorship resistance distributed trust permissionlessness uh here are some things that you could be building with golem and imagine that you have a plugin in your browser that automatically detects

deep fake videos but under the hood just sends the links of the videos uh to golem network that that analyzes them and this is how you know or imagine them like a molok dao version where members are not afraid to vote publicly on something because their vote stays anonymously uh like imagine imagine the app analyzing satellite maps for for illegal tree cutting or illegal buildings that would be like founded and and supported by the community these kinds of apps are are very exciting to us because they benefit from our unique value proposition okay so uh where we are with that

the best thing is golem new golem works and it works since april uh and as i mentioned before like we're uh we're plugging some things like the the market implementation to have a decentralized implementation we're still working on a lot of things around the sdk and testing uh we're building this high-level apis we're working on on layer two payment driver so there is still uh much to be done before mvp but uh we're not going to wait for mvp to show you all of this actually

we're planning like an alpha release like a developer preview really soon so so you will be able to to run it for yourself you'll be able to just go and write your simple request or code and and and run it in golem um you might be asking so what mvp is uh for me mvp is when the network and the protocols and and the implementation is ready uh to host application that has productional users and this is what we're aiming for mvp and uh yeah of course there will be like two execution environments was men and vm execution environment layer 2 payment driver two high level apis

but also we will be preparing inspirational packages for developers and i mean not just ideas uh but you know pieces of product research and tech research and maybe some pieces of code and pair it with like a bounty program so developers can just take it and and and start writing and deploying these apps as as soon as possible so yes we will not be writing use cases ourselves but we will be the stewards of the community and we'll make sure that this applications will be created uh yeah so i think i think that's it if you

if you feel that this is uh something that is interesting for you that you would like to to write an application on on top of new golem uh please do contact us and also check out the release that is coming soon this will also be like a reason to uh to talk to us and give us feedback uh we welcome this every every freaking time uh thank you so much for for having me and and listening tuning in to this presentation and i hope you have a great rest of the conference

uh talk to you soon [Music] [Applause] [Music] so [Music] hello everyone my name is jayun kim

phd candidate studying blockchain at virtual machine and optimization lab at so national university in korea in this session i will talk about our research paper nandy thanos optimizing synchronization for lightweight client on account based blockchain as the ethereum becomes popular the storage size of ethereum continues to increase therefore the size of arkham node is more than 4.8 terabytes as of august 2020 which takes several weeks to boot to strap as a full node fast sync significantly reduces the storage size but still it takes more than 445

gigabytes as of august 2020 which takes several days to put the strap the bootstrapping process is to synchronize to the current state in the latest block to execute or validate new transactions archive sync downloads all the transactions and replace them from the genesis block to the latest block so it is very slow but completely secure on the other hand fast sync downloads all the transactions but replace only the recent ones which occurred after the pivot block that is 64 blocks behind the latest block since fastsync foregoes generating the histories of the intermediate state try it significantly reduces the download

data and bootstrapping time however it is still slow and burdensome why is the first thing stable the sum it is because state-rise synchronization requires numerous t-scales stageria is a data structure to store contributor histories and the number of contracts is 108 billion as of august 2020 it was efficiently designed but as the number of users and accounts increases the tree becomes very large and it causes the storage and bootstrapping problems this is due to the way they try update

accounts when an account is updated ethereum creates an insert new try nodes as many as the height of the try therefore the larger the size of the tri the greater the tri grows for example figure 1 the left shows that block state sigma i of the block i consists of 5 accounts whose addresses are 0x a7 d3 91 which is a1 and 0x a7 d397 which is a2 and so on we represent an an address with six characters for simplicity

and assume that all accounts are eoa if the block i plus one contains one transaction that transfers five ethereum from the accounts a2 to the account a4 with a fee 0.01 ethereum as a result the balance of a2 decreases from 45.01 to 40 ethereum and the nonce increase increases by 1. also the balance of a4 increases from 0.12 to 5.12 ethereum with no change of this nodes a5 is the miner of the i plus 1

round so the balance of a5 is incremented by 2.01 ethereum where 0.01 ethereum is the transaction fee and 2 ethereum is the bloody red this constitutes i plus one as depicted in the middle of the figure as you can see there is only one transaction but 12 try nodes are newly duly created and inserted to the database as you can see below the figure a block of ethereum contains about 200 transactions on average so a thousand of triangles are created and

inserted in each block and and the increasing quantity continues to increase as the tri grows however with careful inspection of ethereum we discovered that almost no accounts are dormant for example only five percent are active in one month and only three percent are active in one week also we observe that many accounts are likely to be updated soon after they are updated for each account we measure the average time distance between two consecutive updates and classify the accounts

by the average time distance we can lastly interpret that an account is updated in a week with a probability of 76 percent and in a month with a probability of 90 so we propose an idea namely thanos to sweep torment accounts periodically to reduce the state try overhead just like thanos who wiped out a half of all life in avengers to achieve the goal eternals defines an epoch epsilon the number of blocks after which it handles this dormant accounts periodically we call the last block of a network a

checkpoint since it is extremely expensive to traverse a state try to find and remove dormant accounts itanos simply creates a new empty strike every time a new app new epoch starts and fill it with the active accounts used by the transactions in the new epoch consequently a miner or a valid or verifier will execute a transaction as usual using the new try to find and update the accounts involved with the transaction since the try is initially empty however no count is available so ethanol's

caches that stay try of the previous previous checkpoint and use it for finding an account state as well that is if an account used by a transaction is not available in the new try we search for it from the cashier try and if it is there copy to the new try and then update it as a result of the transaction if the count is available in neither of the tries when the when the account is a standard of a transaction a restored transaction will be used as really explained later at the end of the current epoch

ethanol caches the current state try discarding the old cache try and then starts a new epoch and the same process repeats the primary reason that etanos caches and uses only the state trial of the previous checkpoint is that this will allow a full node to put the strap only with a single try thus reducing the download size also it will make every full node behave the same instead of using multiple cached trials by some nodes while using one cache try by others following the redundancy spirit of the blockchain

finally the state tries of consecutive checkpoints will include many redundant active accounts so it is more efficient to use only one since the thanos efficiently reduces the status size the increase of state trial slows down as you can see in this figure the number of accounts is decreased from 5 to 3 at the next epoch and also the dually inserted tri nodes which are decreased about 3 at the first and second blocks the effect will be bigger if there are more accounts

these days ethereum has more than 100 million accounts if a transaction you use a derivative account in the current epoch it tells us first we activate city accounts by creating it in the current state try there are two cases if the account is a sender of a transaction it should first transmit a registered transaction which will create the account in its last account state if the account is a receiver of a transaction there are two possibilities one is that the account is the derivative count

and the other is that the account is a new account since it seems in ethereum when someone sends some value to an arbitrary address that does not exist in the current state a new count for that address is created in the state with a nonstop zero we got a list of the existence of the owner sa6 and figure 4. in it tunnels we simply create a new account even for the former case which can reduce the frequency of the restored transactions we call this crown state of the tournament account if such a dramatic tournament the newly

created account becomes ascended later yet without enough balance it will restore itself by merging its account state with the original state a restored transaction is initiated by the owner of a thermometer account but the transaction itself is created and transmitted by an archive node on behalf of the owner then miners and verifiers will run the transaction as other regular transactions so there are three rules involved the owner should first determine if its account disturbance by checking if

two epoch periods have passed since the last occurrence of this transaction or by encouraging if each account is accessible in the current epoch if the account is used once in a while the owner may use a run running smart contract to recast a restored transaction regularly an outcome node who gets a request from the owner we create a resource transaction by accessing the state drives of relevant relevant checkpoints and collecting the essential data which include a marker proof of the account at the last active checkpoint and void

proof of the account at each checkpoint from the last active checkpoint of the latest checkpoint -1 that is a restore transaction should have a proof that the account was active at the last active checkpoint and was inactive thereafter as depicted in figure 5. however avoid proof for the last active checkpoint is none that is not necessary as they can be checked through a caches they try the miners or the verifiers will execute the restore transaction when it is transmitted in the

transaction pool they will verify if the proof and the void proofs are correct using only the state route in the checkpoint block headers and create the account in the current blocked state try we reduce the void proofs by using blue filters as depicted in figure 5b and design the merging process for chrome states as depicted in figure 6a also we prevent already resource state to be restored again as depicted in figure 6b we implemented the tunnels based on guest version 1.9

and compared with the original gas client the evaluation was conducted on a machine depicted here and there are several constraints to experiment the tunnels and original gas with with the rear ethereum data from 7 million to 7.3 million blocks for icon node ethanol reduces the storage size about 10 percent for faster sync at the seventh checkpoint ethernet slightly reduces the storage size however for compact sync which is proposed stink mode that does not download the transactions before the paper block italian significantly reduces the

storage size of a 62 percent and these figures use that the storage size of gas fest ethanol fest can compact a an ethernet compact sink ethanol fast is almost famous the gas fest because of the overhead of the additional resource transactions however the gap between eternal's contact and it gas compact is continuously increasing the slight increase of ethanol's compact is caused by the blockaders finally we measure the synchronization time for the four cases as you can see both eternal fast and complex things are faster than just fast and complex

things and the buddha wrapping time of get fast and compact are almost same although the storage size of get fast sink is about 60 times of that of cat compact stink this means that the steak dry is the real bottle leg of the butter strapping process that's all and if you have any questions feel free to mail me