Cartesi and Energy Web Foundation Keynotes (Combined Recording)

Transcript

[Music] hi my name is eric demota founder and ceo at cartesian cartesi is a project that started in early 2018 with objective to make the apps easier to build and much more powerful we have been building a blockchain agnostic second layer infrastructure that allows the apps to uh move intensive computation over massive amounts of data off chain while retaining decentralization and the same security guarantees of the

underlying blockchain also all the data involved can remain private among the interested parties in the application well so far there are quite a few projects that that are also attaining these uh features in one way or another but what really sets cartesia apart is the fact that the app logic can actually be built using mainstream traditional software stacks on a real operating system so actually we provide a linux runtime environment where the app logic can run so you can use

mainstream software stacks and also os resources like the file system that's quite unique especially if you compare this to the very limited um runtime environments and language let's say of solidity in which developers even struggle to convert numbers to string now a few weeks ago we released the alpha version of our first product the the card sdk the card sdk is a product that provides super powers to ethereum the apps and smart contracts so uh smart contracts are able to

specify a computation in the form of the full linux os and program that runs within it and this computation will run by the card nodes that uh are run by the interested parties themselves so actually the app developer can choose a set of nodes that will run and verify computation of chain typically uh the uh the the nodes will be run either by the the app user themselves or by people or organizations that they trust the important thing about the way that these nodes achieve consensus of chain is that as long as we have at least one

honest node uh the honest node is always able to ensure that the correct results of the computation is persistent on chain so we have a way now that's already available that smart contracts when ethereum are able to specify these complex and intensive computations to run off chain while retaining decentralization and the security guarantees of the main chain so here's a graphical representation of what i just said uh you have a d-app contract that's able to specify the computation and the d-card nodes that are involved run this computation of chain uh sorry a claimer node presents the

results to the blockchain and the other validating nodes are able to verify the claim presented and if one of the nodes see that the claim is false that node is able to start a dispute and enforce that the correct results is persisted on chain so at the heart of the cartesian node we can find our vm which is called the cartesian machine the cartesian machine emulates a risk 5 isa and is able to boots an entire linux os

it is deterministic reproducible and self-contained these are fundamental properties to make sure that consensus is achieved the other important feature is that the cartesian machine is transparent and it's able to produce a merkle tree root hash of these of its entire estates and also merkle proofs of parts of the states that show that the part of the state is consistent with the with the the full state hash it also is able to prove that the execution of one single microprocessor instruction advances the uh the machine from one

state to the next and from one hash represent the states to the next state hash this is very important because we also need a mirror implementation of the risk 5 isa uh in order for the blockchain to verify the proof that one instruction actually takes uh the one state to the next state which is fundamental for the dispute resolution protocol uh finally when the developer is creating uh their d app they need to provide a cartesian machine template

it's basically a template that receives a rom specification a ram image that will contain typically the the linux kernel a root file system flash drive and a set of inputs flash drives and one output flash drive so everything in the cartesi machine is configurable actually the the app developer is able to choose the amount of ram and number position and lengths of the uh of the drives uh over a 64-bit physical address space of the machine everything is configurable by the app

developer according to the the app needs so for the cartesian machine template of course the input drives are empty at the beginning because these input drives are going to be replaced by drives that are going to be fulfilled with the actual information that is coming at runtime when the dx running here we have a sample of how we could instantiate a cartesian machine using the command line interface so you can easily see that through this command one can pass a wrong image a ram image specify the the amount of ram the root file system is giving through a

flash drive and when the machine boots it just executes the sample command ls slash bin and then it holds the cartesian machine provides other ways to for one to manipulate it from the outside so we also have a lua programming language interface a c plus plus interface and most importantly a gr pc interface that's fundamental for the cartesian machine to work inside the nodes and interacting with the blockchain from the inside of the cartesian machine you know the the program sees a full computer and a full linux operating system so it doesn't

know that it is in a emulated environment at all let's give it a break for some time to talk about some cool application that we delivered at the beginning of this year crypts is a tower defense game in which the players compete uh against each other for the high score it's fully decentralized it runs on ethereum thanks to cartesi what's cool about crypts is that is that it involves heavy processing you have billions or even trillions of microprocessor instruction steps that are required to run

in order to verify a gameplay and of course doing that on chain would be impossible due to the computational limits of the blockchain the second important thing is that uh crypts was implemented using typescript and it does among other things compression and decompression of files which of course would also be impossible to do on ethereum because the concept of files is not there so here we have a fully decentralized tower defense game involving heavy computation and mainstream software stacks and os resources

totally working on ethereum thanks to cartesi so if you want to try you can just download it's open source you can even use it as a template to build your own game let's go back to how cartesi works so we spent some time talking about the risk 5 vm architecture which is one of the pillars of the technology and the other pillar is the local consensus protocol i like to spend some more times talking about the local consensus protocol it's a very important aspect of the system if you were to develop a game on ethereum or any blockchain supporting

smart contracts uh and let's say alice and bob would challenge each other on this game then for every every single game move that alice or bob do uh it becomes a transaction in the ethereum blockchain and that transaction with the entailed computation needs to be emulated by around 12 000 full nodes in the network and of course the 12 000 nodes are not interested at all in the results of the match between alice and bob that doesn't concern them [Music]

hi in today's talk i would like to explore how decentralization and self-sovereign identities can help in saving the planet i'm michael the cto of the energy wet foundation my job is to enable the creation of a decentralized infrastructure to decarbonize the grid i love my job the energy web foundation was created in late 2016 with the mission well you probably guessed it to create a decentralized infrastructure to decarbonize the grid the first backers

were the likes of shell and tepco and edf and singapore power group big corporates in the second and third wave in 2017 and 2018 more corporates and more startups were added to form our ecosystem today of over 100 large and small companies who support our mission let's briefly go over the transformation our electricity grid is going through in the past energy markets were very simple you had a utility creating electricity and a customer

purchasing it and that's it and we are in transition actually into a system in which many consumer will become prosumers which mean producers and consumers and the grid will be physically decentralized this decentralization is a big challenge for utilities because they're not used to it another effect of desert centralization is that the spending power is shifting from utilities to presumers according to the international energy agency in 10 years

the presumer ev drivers homeowners small businesses will spend three times more than utilities and 15 times more than today on energy resources this shift comes mainly from the fact that more and more of our everyday appliances like cars water heaters heat pumps air conditioners washing machines well to name just a few will be able to participate in energy markets let's go back to i.t this is our energy web decentralized operating

system the ew dos for short it has three layers from bottom to top trust utility and toolkits the trust layer is the energy web chain which went live in june last year it is an ethereum clone with approval authority consensus publicly usable with a permission validation scheme so you can purchase energy web tokens today on three exchanges actually five exchanges and start building applications on the energy web chain the utility layer contains the building blocks

that will allow application developers to seamlessly write and deploy their decentralized applications without the need to provision infrastructure the toolkits are the use cases we the energy web foundation is working on to decarbonize the grid the focus of this talk is an identity and how it makes toolkits easier to use i will go into more detail on how identities work specifically about authentication and authorization in order to give this a bit more context i will also talk

a little about our flex toolkit for flexibility markets as you might know creating an identity is a matter of generating a key pair and anchoring it on chain it's that simple you can do it from the comfort of your desk once a user or organization has an identity they can create and issue claims creating a claim is done by the user who holds the information they want to have validated claim issuance means approving the data

provided by the user while you can issue a claim to anyone only the owner of the identity is capable of saving the claim in the did document and this is very important because it makes it impossible to write something into someone else's did document without their consent looking at a concrete example alice wants to convince her utility the dso in this picture bottom left that she has installed the battery in her home

and that that can store the energy from her rooftop solar and she wants to participate in flexibility markets with this battery so alice starts by creating a claim that she owns the battery and sends that claim to this device the device contains a secure element with a private key that is capable of signing messages and because the claim is correctly formed the claim is issued back to alice alice can now store the claim that the battery has issued to

her in ipfs she might want to encrypt the claim in order to obfuscate its content which might be a good idea because ipfs is publicly available but simply storing in ipfs is not enough the claim must be anchored on chain to give it legitimacy alice is now ready to prove her to her utility that she owns a battery and presents the link to the claim to the dso obviously the dso does not trust alice and needs to verify the claim the dso fetches the claim from ipfs and

reid reads checks in in the on-chain registry that the claim has not been revoked and that the signature is correct the dso must trust the battery's claims and it can do so because the battery owns a claim in its own did document that it was issue that it was created by an oem and this oem is someone the dso trusts and by delegation of authority the dso trusts the battery a did document can be compared to a passport

in which all the attributes of a person or device are stored the attributes might originate from multiple parties and together give a precise picture of the capabilities of the device and permissions of the person the added benefit is that any application can trust a user's claim and thus there is no need for multiple onboardings because the claims are owned and held by the user themselves

it is the user and not the application developer who can decide to who the claims can be presented and this is actually the biggest shift from centralized schemes to decentralize authorization schemes it is the user and not the application that can decide to who authorization schemes can be presented the did document and the claim it contains can be used to authenticate or verify that a user has access to the private key and that this private key has not been compromised

it is much more secure than a username and password scheme once the user has been authenticated an application can actually authorize the user to do stuff because of the claims that the did document contains and the proofs that the user is able to present that they have access to certain functionality and again application can make use of any of authorization that you as the user have received so let's talk a bit about

how we use dids in our flex toolkit the flex toolkit allows a consortium of dsos and tsos which are the distribution service operator and the transmission service operators or low voltage and high voltage system operators to create a shared flexibility market flexibility markets allow to incentivize presumers to help balance the grid and this effort is required and it is performed today already but not by presumers but it is required for us to enjoy electricity at a stable

voltage and a stable frequency which is really important for our appliances to work in our flex toolkit we have created a hierarchy of trust the government in this picture the authority on the left-hand side of the chart is responsive is the root authority and they're the ones who issue the claims to the dso and tso that this is the role they play in the system the tso actually trusts the judgment of the multiple dsos that it sells

electricity to they have a contractual agreement and it is okay for them to trust one another it is the dso who is in charge of vetting installers approving oems and it is a dso that has the commercial relationship with the presumer and the prosumer is the one who owns the iot device and the installer is the one who certifies that the iot device has been installed correctly and the oem certifies that the iot device let's say a battery has certain capabilities and all these data can be trusted because

the parties that issue the claims can be trusted have developed a mobile application which allows the prosumer to take ownership of their devices and the installer to verify the installation this is important to reduce the onboarding costs for devices and presumers once a device a decentralized energy resource in our jargon or a der has been onboarded it can send offers to the marketplace

it sends offers to deliver flexibility for a 15-minute delivery period and it is the device itself and not a delegate of the device that sends the offer this offer is signed by the device's private key which is held on a secure element on a secure hardware element like a hardware wallet but the device being dumb it needs to be instructed how to create the offer or what the parameters of the offers are it is the owner of the device that can delegate the power or the authority to instruct the device on how to make its offers to

an intelligence provider or an aggregator or whoever can provide this service this is really important for the device to make good decisions and good offers and it can be a competitive market for the future once the offers have been purchased which is not guaranteed of course it's a marketplace the dso or tso who has purchased the offer can use the acquired privilege to direct the der to do their bidding either consume more energy or release energy into the network so if there is a glut of energy

the sun is shining too bright there is too much solar let the batteries charge and once a cloud passes uh between the sun and the solar panel let the batteries discharge at the end of the 15 minute delivery period um the settlement is done so the payment is done this is of course done on chain on the energy web chain and the offer is settled according to the price that has been agreed on if you would like more information here is a collection of links pertaining to the subject

and everything we do at energy web foundation being open source you are free to go on github and well explore the source code for yourself thank you very much for listening so far and have a great conference [Music] you