WIXLIB

The EW-DOS Tech StackFig. 1TRUST LAYERBlockchain technology has two primary valuepropositions: 1) multi-party consensus about the stateof data and 2) trust that a given application or smartcontract will behave in a predictable, deterministicway.In EW-DOS, the EW Chain provides trust. It is a public,proof-of-authority Ethereum Virtual Machine (EVM)based on the AuRA consensus protocol. Energy Webmember organizations operate and maintain the EWChain by hosting validator nodes. They include largeutilities, grid operators, and technology companies.As of Q2 2020, more than 25 validators support the EWChain, with over 30 validators expected by Q4 2020(the technical limit in AuRA is 150 nodes).The EW Chain features a native utility token (EWT)that is used to pay for transactions and other EWDOS services. As an EVM blockchain, the EW Chainalso supports all ERC standards. This includes simplefungible ERC20 and non-fungible ERC721 as well aslesser-known transferable certificates ERC1888 andmany more. In addition to the main EW Chain, thevalidators also support a test network (i.e., sandboxand QA environment) called Volta, which can be usedto evaluate pilot projects.EW-DOS: The Energy Web Decentralized Operating SystemSince its launch in June 2019, the EW Chain hasexecuted approximately 1.1 million transactions over5.5 million blocks. In that same period, the Volta testnetwork (a technical replica of the EW Chain used forproof-of-concept and pilot applications) has executedapproximately 30 million transactions over 6 millionblocks. To date the upper boundary of transaction feeson the EW Chain is approximately 0.00015 EWT andthe vast majority of fees range from ten-thousandthsto millionths of one EWT; it costs no more than a fewcents to fill a block with transactions.The EW Chain’s PoA consensus mechanism currentlyenables roughly two to three times greater throughputcapacity than the Ethereum mainnet thanks to fasterblock time (in the future, the EW Chain can potentiallyenable up to 7.5 times greater throughput capacityvs. Ethereum via a higher gas limit). The EW Chain’scurrent parameters of a five-second block time anda block gas limit of 8 million translate into a rate ofapproximately 76 transactions per second (or 380transactions per block), though in general transactionsper second is not the best metric for measuringscalability (not all transactions are equal in terms ofcomplexity and computation). A more relevant metricis gas limit (a measure of computation) per unit oftime; for example in a 15-second period the EW Chaincan execute 24 million gas (over three blocks) whichis more than double public Ethereum (currently 10million gas at a 15 second block time).7

UTILITY LAYERThe Utility Layer, analogous to the “middleware”layer of the EW-DOS stack, streamlines the experienceof creating and managing applications by givingdevelopers tools to easily build solutions that gain theadvantages of decentralized digital infrastructure yetdeliver familiar UX to customers. The services providedby utility nodes in the Utility Layer are priced and paidin EWT.The Utility Layer addresses three broad categories ofuser experience / enterprise implementation:End-User Experience:Energy Web Name Service (EWNS): Decentralizeddigital identities (DIDs) form the basis of mostinteractions in EW-DOS, but as-built, they can bechallenging to use (e.g., few will ever memorizethe hexadecimal string that represents theirDID). EWNS dramatically simplifies the processof managing DIDs and makes it easy for usersto interact with contracts, addresses, andapplications by mapping human-readable namesto DIDs and blockchain objects (the same waypeople-friendly website addresses point to hardto-remember, long, numeric IP addresses). Userscan simply map an EWNS name (e.g., name.ewc)to their DID address and create a sub-name for anunlimited number of other resources, like an emailaddress, contract interface/address, or any otherarbitrary metadata (e.g., resource.name.ewc.).With EWNS, DIDs truly become universal passportson EW-DOS: users gain the ability to interact withtheir DID and other applications in a way thatmimics the existing internet, and developers canreserve EWNS domains for their applications and/or users.DID Key Recovery: In the EW-DOS DIDimplementation, the DID is itself a smart contractgoverned by a key pair. In the event that the DIDowner loses control over the original key pair, theKey Recovery solves the “password reset” problemand prevents adversaries from unilaterally gainingcontrol over their DID. This custodial serviceestablishes a multi-signature wallet that governsownership over the DID. When first creating a DID,the identity owner would not just create the DIDEW-DOS: The Energy Web Decentralized Operating Systemcontract and associated key pair but also delegateauthority to two or more known, trusted parties(e.g., peers, utilities, etc.) to validate any futurechanges to the DID ownership. In this system, theidentity owner simply creates a new key pair andperforms the necessary verification steps with thedelegated authorities to port the DID ownership tothe new key if/when necessary.Transaction Relay: A transaction relay server thatenables fire-and-forget transaction submission,checks whether the transaction is mined, andresubmits it in case of error. This relay also allowsusers to interact with the EW Chain withoutneeding to hold / deal with EWT directly, ineffect creating the same UX as traditional webapplications. This enables application developers(e.g., utilities, grid operators, service providers)to build user-facing applications in which usersperform transactions (e.g., create DIDs andmanage DID claims) while a delegated proxy nodepays for transaction fees in EWT.Cross-Platform Interoperability:Bridges: As blockchain technology continues tomature, we expect multiple blockchain platformsand protocols to emerge for specific use casesand/or geographies. To enable identities andcontracts running on the EW Chain to interact withpeers on other blockchain networks, purposebuilt smart contracts called bridges are used.The first two production bridges are designedto transfer tokens between the EW Chain andthe main Ethereum network; one enables usersto transfer native EWT from the EW Chain to anERC-20 representation on Ethereum and the otherenables users to transfer DAI stablecoins fromthe Ethereum network to a bridged DAI on theEW Chain. Over time functionality will expand toenable any arbitrary data or transaction to occurbetween networks, for example using the ArbitraryMessage Bridge to trigger interactions betweensmart contracts on EW Chain and Ethereum. Thiswill create a universal base layer for buildingbridges between EW-DOS applications andapplications on any other EVM-based chain.8

Oracles: Blockchain-based smart contractscannot fetch data from external systems, yetin nearly every energy-sector use case smartcontracts and events require data inputs fromoff-chain events or systems. For use cases whereit’s beneficial to leverage multiple input sources(e.g., monitoring of local voltage for multi-partyreconciliation, reporting of distributed solar forrenewable portfolio standards accounting), weare building on top of emerging open-sourceprotocols, particularly the Chainlink protocol,for establishing a network of independent nodesto provide event data to on-chain contracts. TheEW-DOS decentralized oracle implementationeliminates single points of failure and can reducefriction in market transactions by accepting datafrom multiple sources concurrently. Setting up anoracle on EW-DOS involves configuring dedicatednodes that execute specific steps to retrieve,interpret, and aggregate external data.Other Chain Abstraction: Going forward wewill continue to develop other services and toolsthat make it easier for users and applications tointeract with the EW Chain. Examples includea smart contract application programminginterface (API) generator that provides a standardcommunication interface between on-chainidentities and contracts and off-chain systemsand data through usage of GraphQL or RESTFulmiddleware, the EW Chain station (which enablesapplications to fetch real-time gas prices (inGwei) from a public end point), and the EWWallet, which provides a simple user interfacefor managing EWT. Additionally, most enterpriseimplementations will feature custom architecturesof orchestration services that securely connectlegacy IT systems (e.g., customer relationshipmanagement, enterprise resource planning,billing engines) as well as IoT devices to on-chaincomponents. Designs range from server-sideintegrations into big SCADA systems to small,lightweight implementations that can run on asmall IoT device.EW-DOS: The Energy Web Decentralized Operating SystemApplication Performance:Identity Directory: Decentralized Identifiers(DIDs) are a new type of identifier for verifiable,persistent, resolvable, and secure digital identitiesthat are directly owned and controlled by endusers. DIDs are URLs that relate a DID subject(e.g. person, organization, asset) as a means fortrustable interactions with that subject and canbe implemented independently of any centralizedregistry, identity provider, or certificate authority.DIDs resolve to DID documents, which describehow to use that specific DID. Each DID Documentmay express cryptographic material, verificationmethods, and/or service endpoints. These providea set of mechanisms which enable a DID controllerto prove control of the DID. Service endpointsenable trusted interactions with the DID subject.At the most basic level, a DID is simply a smartcontract governed by a public-private key paircontrolled by an individual or organization; thekey pair resides on a decentralized networkthat is not controlled by any single party. Assuch, the end-user is ultimately in control oftheir digital identity and can grant access orsupply information to other actors as needed.The EW Chain DID implementation is based onthe W3C DID standard. The identity holder (the“subject”) can add as much information as theylike to their identity (i.e., claims) and they can getthis information verified by authorities (e.g., agovernment, energy company, bank). Collectively,this process authenticates an identity. Theseverified claims can then be used to selectivelydisclose information to third parties, akin to aperson proving that they have a valid driver’slicense by showing the expiry date and the picturebut without disclosing their home address, name,or age. The core Identity Directory is a smartcontract that contains the universal list of DIDsand associated claims on the EW Chain. Thisarchitecture gives end users greater agency overhow their digital identity (and associated data,vis a vis DID Documents) is used and stored while9

also offering seamless interoperability with alldecentralized applications running on the EWChain. DID Documents provide a structured way todefine:Authentication Mechanism: By which the DIDsubject can provide a cryptographic proof ofthe control over its identity.Public Keys: The DID document can list theauthorized (RSA and ECDSA based) keys toprovide digital signatures and encryptionoperations.Authorization and Delegation: A DID canauthorize or delegate another DID Subjectto perform certain operations on its behalf.The authorized or delegated DID can servedifferent business process related operations.Service Endpoint: The service endpointslisted in the DID document of the DID subjectprovide a lookup mechanism for addressableURLs to interact with the DID subject.Messaging: In general, it is only practical toperform messaging on-chain when the message(or related event) requires establishing multi-partyconsensus. EW’s enterprise-grade decentralizedmessaging infrastructure enables high-volume,low-latency (e.g., machine-to-machine)communications that do not rely on blockchaintransactions. In conjunction with the identitysystem, the messaging service creates a secureand trustworthy communication layer that doesn’trely on any single party. EW’s messaging solutionbuilds on established standards (e.g., AMQP,MQTT, STOMP) and is built in such a way that theinfrastructure can be decentralized; any qualifiedentity can operate a node or set up their ownservice.EW-DOS: The Energy Web Decentralized Operating SystemThe core characteristics of the messaging solutioninclude:A DID-based authentication mechanism forparticipants to establish permissions based ondefined criteria (e.g., geographic location);Enforced signing of messages to validateauthenticity and implement on-chainsettlement;Integration with MQTT, AMQP, and STOMPclient and server architecture.Storage: Given the volume of data in the energysector, as well as the complicated regulationsgoverning its use, it will be impractical to storedata on blockchain at any reasonable scale. EW isdeveloping a decentralized data storage solutionfor content-addressed and key value data, but inmany cases existing storage solutions (e.g., eitherprivate cloud or on-premise database) will be usedfor commercial applications and the messagingand other chain abstraction components will serveas a connective layer to on-chain components.The storage system has two types of elements:Content-addressed: The content-addresseddata are those which must not be editable.This includes: services for DID documents,files. We are experimenting with IPFS, whichwas used for the implementation of the firstclaims store for the DID library.Key Values: The key-value data containsthings that need to have a predictable key oran arbitrary key. Examples include: state of anEVSE, reference to the latest version of an app.We are working to repurpose existing, centrallymanaged key value stores like couchdb, Redis,and Ignite.10

TOOLKITSToolkits are like blueprints for building decentralizedapplications on EW-DOS. They provide genericfunctionality common across many different marketsand use cases, but need to be customized andimplemented within a specific context to createbusiness value.Application Registry: EWF’s applicationregistry reference architecture provides marketparticipants a standardized way to create bespokeregistries with administrative features specific toa particular geography, market, or application.Application registries act as an “authorization”layer, setting the rules and roles for DIDs that wishto participate in the given market. For example, anational grid operator may create an applicationregistry that dictates eligibility for participation ina wholesale market (e.g., DID must have verifiedclaim as being a qualified DER and that claim mustbe signed by another DID that has a verified claimfrom the national regulator). Every decentralizedapplication (dApp) running on the EW Chain willhave at least one application registry, but a givenapplication registry can be applied to multipleapplications (in the example above, a distributionutility could coordinate with the national gridoperator and use the same registry for a localcongestion management program). EW’s referencearchitecture includes a series of open-sourcesmart contracts and dApps for managing changesand updates to the registry and creating an audittrail of all interactions between DIDs within theregistry.EW Origin: Origin is a family of software toolkitsthat support “proof-of-impact” applications fortracking, trading, and reporting energy attributecertificates (EACs) based on industry standards.Applications built using Origin can be used for 1)creating a digital registry of buyers, sellers, assetowners, and regulators to issue and monitortransfer of digital EACs; 2) creating a digitalmarketplace to trade, claim, and report EACs thatintegrate with existing EAC registries, includinglegacy systems that do not use the EW Chain orEW-DOS: The Energy Web Decentralized Operating SystemOrigin (e.g., the I-REC Standard); and 3) enablinggeneration devices to self-register in appropriateregistries, automatically report their operationaldata, and consequently access relevant EACmarkets. Origin leverages the multi-token standardERC-1155, which combines a non-fungible tokenwith a fungible component that is similar toERC-20 tokens and can therefore be transferredand bundled in a similar way. In detail, the nonfungible token stores the device information andtime frame of the certificate and the fungible partstores the energy volume that has been generatedin that time frame. Origin consists of four modules:Registry: The registry module stores andmanages user and device information toinform subsequent participation in EACmarkets/programs. The registry enablesboth on- and off-chain storage capabilities,ensuring that private information is safely andsecurely kept away from the public domainwhile leveraging on-chain proofs to ensurethat off-chain data is verifiable and tamperproof.Issuer: The issuer module enables EACissuers (e.g., regulators, standards bodies) tomint EACs upon request based on providedgeneration evidence. Besides just mintingnew EACs, the issuer module also ensures thatthe certificate lifecycle adheres to relevantlocal regulations; each regional platform orapplication has its implementation of theissuer module.Exchange: The exchange module facilitatestrading between buyers and sellers of EACs viaan order book system where sellers post asksand buyers post bids. Once there’s a matchbased on EAC criteria and price, the trade isexecuted and the EAC ownership is updated.User Interface: The UI module is the glue thatconnects all underlying modules and makesthem accessible to the end-user. It’s also ademonstration of how easy it is to build anopen, transparent, and regulatory-compliantmarket for EACs around the world.11

EW Flex: Flex is an open-source softwarearchitecture for coordinating asset (e.g., DERs,electric vehicles) data and operations acrossorganizational and technological boundaries.Flex solves existing pain points in harmonizingtransmission- and distribution-systemoperations, managing an ever-growing fleet ofdiverse distributed energy resources (DERs),and reconciling data among participants inwholesale markets or across information andoperational technology systems within verticallyintegrated utilities. Flex consists of a seriesof modules that address the full lifecycle ofDER participation in wholesale markets and/or demand-side management programs, fromprequalification through settlement. Flex was bornout of requirements for integrating one milliondistribution-level, behind-the-meter batteries intoa wholesale frequency regulation market, but canbe applied in any regulatory or market contextfrom utility “bring your own device” programs,to deregulated competitive markets, to emergingelectric mobility programs. Flex is a modulararchitecture featuring four modules:Flex Nodes: Decentralized clusters thatprovide and execute the business logic of themarket or program. Nodes are responsiblefor managing the lifecycle of asset offers (oroperating schedules), and also implementalgorithms for optimizing the matching ofoffers and requests according to the specificuse case / market rule. By varying thefunctionality of the nodes, grid operators canprocure a multitude of different services fromcapacity, to energy, to ancillary services.either based on cryptographic chips ormobile SIM cards. It also allows the assets toparticipate automatically in energy markets bycryptographically signing flexibility offers and,at the same time, verifying incoming requestsfor flexibility. The Flex UI and Flex Mobileclients provide fr

EW-DOS The Energy Web Decentralied Operating System 6 As a nonprofit organization, we don't have shareholders and everything we do is in pursuit of our mission to decarbonize the global energy sector. Accordingly, EW-DOS is not a product, or an application, or a market design. It is an infrastructure. EW-DOS is an open-source, public, digital