{"title": "Ethereum Distribution System", "logoImg": "bafkreidgazt4uywma7sb2ok7xmws5sqokbwtryzp7vmuvj35fnhdoflssm", "website": "https://github.com/peeramid-labs/eds", "bannerImg": "bafkreigrptkxzann6upc6lh5ragj6a2mb4m2zpoiw7xrrwh6hiz7nfteoy", "createdAt": 1723052779970, "userGithub": "peersky", "credentials": {"github": {"type": ["VerifiableCredential"], "proof": {"jws": "eyJhbGciOiJFZERTQSIsImNyaXQiOlsiYjY0Il0sImI2NCI6ZmFsc2V9..tbYwYYXjqVD2ThRoH5mkBOZbkUiIBbzHXw6flHgzx5n_7ZGLR2c8Wvcj5c7ifpV1_kVKm7BbG7aVHotMw4q0Cg", "type": "Ed25519Signature2018", "created": "2024-08-07T17:46:08.105Z", "proofPurpose": "assertionMethod", "verificationMethod": "did:key:z6MkghvGHLobLEdj1bgRLhS4LPGJAvbMA1tn2zcRyqmYU5LC#z6MkghvGHLobLEdj1bgRLhS4LPGJAvbMA1tn2zcRyqmYU5LC"}, "issuer": "did:key:z6MkghvGHLobLEdj1bgRLhS4LPGJAvbMA1tn2zcRyqmYU5LC", "@context": ["https://www.w3.org/2018/credentials/v1"], "issuanceDate": "2024-08-07T17:46:08.105Z", "expirationDate": "2024-11-05T17:46:08.105Z", "credentialSubject": {"id": "did:pkh:eip155:1:0x2e8d906A63D15E110037DB42dD24FE69bEc4aFAf", "hash": "v0.0.0:zCilqRLMJ+Zr/0dUufetkRFOmC7NMoQMXad5KHweg18=", "@context": [{"hash": "https://schema.org/Text", "provider": "https://schema.org/Text"}], "provider": "ClearTextGithubOrg#peeramid-labs#61459744"}}, "twitter": {"type": ["VerifiableCredential"], "proof": {"jws": "eyJhbGciOiJFZERTQSIsImNyaXQiOlsiYjY0Il0sImI2NCI6ZmFsc2V9..crpw1I3TibKFrxsu0hp38nHwhWR1biMuvYDPZqJLNeet4RJ1WB5L9wfJ-cS_HuRUBMVPwV0yk3iabKzLkzwhCg", "type": "Ed25519Signature2018", "created": "2024-08-07T17:46:02.123Z", "proofPurpose": "assertionMethod", "verificationMethod": "did:key:z6MkghvGHLobLEdj1bgRLhS4LPGJAvbMA1tn2zcRyqmYU5LC#z6MkghvGHLobLEdj1bgRLhS4LPGJAvbMA1tn2zcRyqmYU5LC"}, "issuer": "did:key:z6MkghvGHLobLEdj1bgRLhS4LPGJAvbMA1tn2zcRyqmYU5LC", "@context": ["https://www.w3.org/2018/credentials/v1"], "issuanceDate": "2024-08-07T17:46:02.123Z", "expirationDate": "2024-11-05T17:46:02.123Z", "credentialSubject": {"id": "did:pkh:eip155:1:0x2e8d906A63D15E110037DB42dD24FE69bEc4aFAf", "hash": "v0.0.0:6kl0jXAyf0oPUpVFVR2mdnqmW/YnAPynu/LFvHt6Toc=", "@context": [{"hash": "https://schema.org/Text", "provider": "https://schema.org/Text"}], "provider": "ClearTextTwitter#peeramid_labs"}}}, "description": "# Ethereum Distribution System\n\nThe Ethereum Distribution System (EDS) is a open and decentralized, fully on-chain distribution system for Ethereum smart contracts.\nEDS maps functionality, expressed as bytecode, to on-chain locations, using a global non-permissioned singleton indexer contract. Using this index, EDS provides developers with a built in system for [Semver](http://semver.org/) versioning, managing multiple versions and distribution of their smart contracts. System provisions for generic interfaces for distributors, developers and installers, each with their own responsibilities and constraints.\n\n## Overview\n\nThis system acts as generalized and efficient factory which is designed in one-fits-all principle. It achieves this by referring bytecode instead of location, enabling code queries by bytecode hash (`address.codehash`). Developers when interacting with the system first must register their bytecode to the code indexer contract. After that, they may create a distribution contract that links multiple various required code hashes in one place. If the developer wants to manage multiple versions of the same resource, they can create a repository contract to add own index on top of global. In order to provide functionality to users, developers may pack their code to Distributions, which have hardcoded instructions for instantiation. Such hardcoded bytecode later can be itself consumed by Distributors, which are responsible for determining custom instantiation arguments and initializer interfaces that will wrap the Distribution. Finally, Installers are used by end-users to manage resources and permissions\n\n### Key Features\n\n- **Verifiable:** Stateless distribution components are easily verifiable by anyone through their bytecode.\n- **Permission-less:** Anyone can deploy distribution components without requiring permissions.\n- **Inclusive:** Can accommodate already deployed on-chain functionality.\n- **Versionable:** [Semver](http://semver.org/) based versioning can be applied to manage resources.\n- **Plug-n-Play:** Installation procedures,easily customizable for any target platform are provisioned.\n- **Secure:** Isolated contract sets and baked-in runtime checks enable trust chain between developers, distributors and users.\n- **Efficient:** Extensive reuse of the same bytecode reduces gas costs, increasing efficiency across the industry.\n\n![image](https://github.com/user-attachments/assets/52fa7028-177c-4de2-9259-3f883491a3d3)\n\n### Key Components\n\nSystem components are broken down into four domains: Permission-less, Developer, Distributor and User. Each domain has its own set of contracts and interfaces, which are designed to work together to provide a seamless experience for developers and users.\n\n#### Permission-less Domain\n\n##### CodeIndex\n\nA stateful, permissionless contract allowing anyone to register associations between bytecode and its on-chain location. Any smart contract may be indexed by `CodeIndex` based on its bytecode.\nProposed `CREATE2` implementation with deterministic address : `0xc0d31D6A64D1BE49867158ed3c25152D240b5c0B`\n\n##### `Distribution`\n\nInterface for contracts that allow specific mechanics of instantiation of referred bytecode identifiers in the `CodeIndex`. It may be using different methods for instantiation, yet it is ultimately referred by it's bytecode hash and instantiation methods kept non-parametric, to promote hardcoding of instantiation logic by the distribution creator, ultimately making any distribution a unique part of code ecosystem.\nIt also allows distribution creators to associate own metadata with the distribution, such as URIs defined in [ERC-190](https://eips.ethereum.org/EIPS/eip-190) or [ERC-2678](https://eips.ethereum.org/EIPS/eip-2678)\n\n#### Developer Domain\n\n##### Repositories\n\nRepositories are interfaces provided for stateful, permissioned contracts allowing developers to manage resources and versions. Such repositories may return any kind of source code reference, including system-internal used ones, like `IDistribution`. It allows developers to increment versions according to [Semver](http://semver.org/) as well as implement version requirements lookup for the clients.\n\n##### Non-Stateless Distributions\n\nAny implementation of Distribution interface mentioned in the Permission-less Domain, that is stateful is considered as a Developer Domain component. It is possible in principle, yet will be used only for specific use-cases, where stateful distribution is required and will require distribution users to use direct location addressing, effectively excluding it from the global index system.\n\n#### Distributor Domain\n\n##### Distributor\n\nStateful, permissioned contract interface for managing distributions. It allows distributors, who may act as trusted source for many, to have their own index of trusted distributions coupled to any, parametric, initialization logic that they might need. This is a first point on instantiation chain that allows to configure distribution after it's been instantiated.\n\n##### Version Distributor\n\nSame as Distributor, but with additional functionality to manage versions of distributions. It allows to manage multiple versions of the same distribution and to provide version requirements lookup for the clients. Distributor may change the version of the repository, effectively disabling, in one go, every outdated version instances from operating in the system.\n\n#### User Domain\n\n##### Installer\n\nStateful, permissioned contracts for managing permissions and accessing targets from multiple distributors. Allows end-users to manage trusted sources for their installations.\n", "logoImgData": {}, "bannerImgData": {}, "projectGithub": "peeramid-labs", "projectTwitter": "peeramid_labs"}