ERC: Proxy Account #725
Comments
|
This is a very useful ERC. I would remove all the Must and Should comments regarding types of keys as it should really be left up to the implementation of the contract. Some contract types might want to have the admin functions, like you should either add a second boolean parameter to say either you approve or not, or add a second function called |
|
I added the Concerning the flexibility of key addition/removals, i added: Which includes either using key type 1, or the identity itself, e.g. then only the identity contract itself can call those function, and they always go through the approval process. |
|
It's just that I don't believe defining key types should be in the scope of this ERC. For some cases, like a democracy, the strings can represent different types of agents: voters, election officials, ID validators, those who can propose new stuff, etc. For a more hierarchical organization, type can be a number representing their rank: for some smaller is more important, for others, bigger is more important. |
|
The reason to add key types, is to prevent people from running around with keys, which can overtake their identity, but rather only use they action keys on a daily basis. Those wont have the ability to remove or change keys, which reduces the risk to loose your identity all together. The other advantage is that it allows to define purposes to keys, which other entities or contracts can then use to derive the purpose of a user action on their system. E.g. if key type |
|
I would like to see some details/arguments as to why this benefits from being a standard. In what ways do we gain interoperability benefits from having this standardized? What types of general purpose tooling are we expecting people to build that will need to work with unknown future implementations of this? Looking over the methods, it seems like a large number of them would qualify as "implementation details" and are not relevant to creating an generic identity management standard. For example, how a particular identity provider does key management is not something that needs to work with many tools, it just needs to work with the identity provider's tool suite. Even some contract that supports 10 identity providers and wants to interface with them all presumably needs to trust those providers in advance, meaning they don't need to build their contract to support arbitrary future providers. Given the current motivation section, I would recommend that this not be a standard and instead just be a contract/dApp that anyone can write and deploy. 😄 |
|
@MicahZoltu I disagree there. If I'd like to be able to use an identity in Mist, it means that I want to create an account, allow that account do things on behalf of others. What I mostly need to be standardized is the addKey, execute and approve. We can use our own private contract, but I think it's nice to try to work together with others. |
|
This needs to be standardized so that other contracts can interact with real world identities, automatically check and verify them. It’s not mainly necessary for interfaces alone. Also this contract represents ONE identity. The addition of claims need to be standardized, so that other identities can issue claims about each other. Verifying an identity would happen in the following ways:
But I assume over time known and trusted issuers will appear so only one check needs to be done. I might write an extra document to explain all the ways of how one can interact with this contract. But I would like to keep that apart from the ERC itself to keep it easy to read. |
|
In order for there to be value in a standard there needs to be interoperability concerns that are being addressed. We don't need a standard for prediction markets, or a standard for exchanges or a standard for gambling games unless there is a compelling argument as to how one of these things would be better if they were interoperable. There isn't significant value in making it so all gambling games have the same interface, since users will interact with each gambling game via a dApp custom built for that gambling game. A good example of useful standardization is token contracts. There is value in standardizing tokens so that an application (e.g., Wallet, exchange, etc.) can interact with any token the user provides without needing to know about it in advance or write custom integrations for each token. However, there is little to no value in standardizing how tokens come into existence because there isn't a strong need for a general purpose UI for token management. Each token author can build a token management UI just for their token, end users won't be using this so it doesn't even need to have a familiar interface. @alexvandesande You have indicated that you want @frozeman It sounds like you have a grand vision in your head that isn't expressed clearly in this EIP or discussion. I would love to hear more about it. As a dApp developer who wants to verify the identity of someone interacting with my contract, I need to go to an identity provider that I trust and and say, "account X claims to be UUID Y, please verify" (or similar) and they would then return true or false. This is certainly useful, but I do not see where in this process a standard adds value. Since I need a pre-existing trust relationship with the identity provider, my dApp won't be accepting any random identity provider that a user gives me. I must integrate my dApp with specific identity providers, and in almost all situations I can think of I will pick one (and only one). To be really clear, I'm not arguing that Identity Providers are bad. I'm arguing that creating a "standard" (and going through the RFC process) for every useful contract someone can think of is bad. There may be value in this being standardized, but it is not immediately apparent to me and I want you to convince me that standardization adds value. Edit: In case it isn't clear exactly what I'm looking for, I would like to see a problem statement that shows some problem that can't be solved without a standard. Right now this EIP is missing a problem statement. |
|
Some upfront definitions would be good. What are keys? Are they cryptographic identities? Why not addresses? What is a claim for, and how does it work? Interface definitions probably shouldn't contain Solidity-specific types (eg, I agree with @alexvandesande that principal types should be left up to the implementation. Role accounts are a good thing and should be encouraged, but there's no need for the spec to mandate what roles exist and what privileges they have. @MicahZoltu I believe the purpose of standardising this is to allow multiple clients (eg, wallets) to interact with multiple implementations of identity providers (Eg, multisigs, etc). Without a standard, you have the current situation, where Mist has native UI for multisigs, but only for its own API, Parity has another, and so forth. |
|
@MicahZoltu i see this needs a lot more explanation. I kept the standard description concise to make it readable, but many of the concepts i introduce here are not apparent right from the start. I will address each of these points here in the discussion, but also keep in mind, as i wrote above; the ERC draft is not finished yet. First of this is a standard for a self sovereign identity; This means the owner controls its identity and he allows claims about himself to be attached to his identity. There are no identity providers, but claim issuer (or certifiers). Those simply say: "I saw him in person, stored his biometric data, and attached a link on his identity". People who want to verify that they are dealing with a person, either in their contracts, or dapps, websites, etc. can then check on their identity - given they got a signed message from one of its keys - and look for a claim they trust. But to answer you questions:
Do i think all of the current proposed functions need to be standardised? No; i just wanted to give a more or less complete set of functions, which make clear how they interact together.
The whole example above, won't work automated and with unknown parties, if these processes and functions aren't standardised. Another extension of this could be that you have to hop through multiple claim issuers, to reach one you trust, which in return makes you trust all the others, including the one you verify the identity of. Also every claim issuer, needs to implement this identity interface himself, to make sure he is verifiable himself (and keys can be checked). @Arachnid concerning key types: If we standardise them we allow many upcoming use cases for keys, as described in my previous comment. Currently i only propose two types: Claim types in return need to be predefined, to allow somebody who wants to verify you to look for what he want a proof about you. I choose the word keys, over addresses as this is better understandable in the "off-chain" world. Keys are something we use on a daily basis to get into houses and objects, and the term is used in cryptography as well. Addresses is very blockchain specific. Though your identity contract address - i would call "address". The current draft allows for all kind of different key management implementations, it doesn't force any, expect that there have to be at least one second step of approval to "MUST only be done by keys of type 1, or the identity itself. If its the identity itself, the approval process will determine its approval." (There is certainly a lot of improvement potential here, and when we think of compatible UIs, we will need to revise that) Many of the above concepts may not be clear yet, but they are in the description of the ERC as a very concise sentence: "This identity can hold keys to sign actions (transactions, documents, logins, access, etc), and claims, which are attested from third parties (issuers) and self attested, as well as a proxy function to act directly on the blockchain." |
The problem is, 'keys' has a specific use in cryptography, and you're using them to refer to something that isn't a cryptographic key, or necessarily controlled by one. I'd really suggest choosing a different term. In either case, the EIP definitely needs a definitions section. |
|
I agree we should add a definition section. Short answer to the above. ‘Keys’ here can be public keys or other contract, like multisigs and reputation systems. If anybody has a better word for them, I’m happy to change that. |
|
claims : |
Exactly. I'd like to be able to login with my uPort identity into Mist, use my Mist identity in Status, or log in with my Status identity on a ether play game or post a blog post in Steemit from my Aragon Company identity. Each one can be implemented differently, just keep some common interfaces. |
|
This is very interesting and it overlaps a bunch with stuff we are doing with uport. Although we have a quite different design I think discussion and standardization around this will be very usefull. I'll give a breif description of our design before I go on. As the base of our identity we use a very simple proxy contract, see also ERC: Proxy standard. This makes our system very flexible in terms of how you can control an identity. I think this ERC touches two very interesting things, transaction execution and claim structures. Transaction executionThe ClaimsWe've opted for not storing claims in the identity contract itself, this makes it cheeper to depoy identities while claims can still be associated with the identity with the same level of security. |
|
I agree with @Arachnid - 'keys' should refer to cryptographic key. @frozeman Great initiative! This is so needed. It's a great step forward a standard for a self sovereign identity but it will not prevent people from creating more than one identity which is a no-go regarding KYC institution requirement process. Except if the identity public address is linked to multiple trustworthy services. |
|
@overdrev I’m not sure if a Claim permission process is needed, except when an entity wants to know the details of the claim, e.g. see the biometric data stored by the issuer. Then of course we need a async process. I have made some thoughts about that, but this is not really part of this ERC and can be a separate standard. I see it as follows: claim data (referenced by ‘bytes claim’) is double encrypted by the issuer and me, if somebody wants to see the actual data they request it at the issuers ‘bytes _location’ and request the issuers part to be decrypted, then they come to me and ask for decrypting the second part, which i can always decline. For b. I’m not sure how a single claim proof should look like, but interesting idea. @oed thanks for participating, you guys should have actually started that standardization process ;) Transaction execution: the excite function is mainly to act as your identity on the Blockchain in the least cases this contract should and will be used for storing and sending ether. If you want to move money and what that to be publicly visible and attached to your identity, use a multisig, or a wallet which is controlled by your keys from your identity . Claim storage: I do understand you wanted to create a system which is cheap in gas, as uport will overtake most transaction costs in the beginning, but I don’t think this applies for a self owned standard, and would be the wrong approach to that. At the same time when a standard is found and a library is deployed, deploying a contract which uses that library is quite cheap. Claims themself will be added by others, the owner of the identity will only pay for the confirmation. As I think A real used identity won’t attach every new app, or social network as new claim, those claim additions will be rather less. Things like this will be stored in other Reputation systems or uport like systems and can be attached as a self made claim to my identity, this way the identity can be kept rather raw. The “cool” stuff can happen on other experimental systems. I’d say there are two main reasons why claims should be with the identity contract:
There is probably more reasons, which don’t come to my mind now. Concerning privacy: as the claim data is only meta data, the only viable information one can retrieve from your identity is: which claim issuer has claims about me (e.g. the German state, or Vitalik claims something about me), and when that data has changed. This can be an issue, if I don’t want anybody to know I live or are German, but we share a lot more information on social networks daily. Also privacy focused claim provider can pop up, which claim things, like address etc globally, but are trusted by many. Then the only thing it leaks, is that you are privacy focused :) @bneiluj people will have more than one identity for sure, as we just start to experiment with this, but once your have gone through the effort to get claims about biometric data and address, etc. you will treat this identity as more valueable. As long as you can add new claims of importance to more than one identity, that’s fine too. The person verifying your identity doesn’t need to care, as long as he can trust the claim issuer. |
|
@Arachnid I added a definitions section. I’m still open for better names for |
|
@frozeman Anything other than keys, really. I'd suggest 'principals', for instance. It's still not clear to me what goes in this field. The definition says "public keys", but contracts don't have public keys. What would the 'key' for a contract be? |
Actually I don't think that's how I would recommend. You can sign your tweet with any account, publish and say: "I am tweeting in behalf of foo.eth". Then the tweet app can check either that account is listed in one of these keys. No on-chain transaction required. |
Example discussion: ipfs/ipfs#227 |
|
Is the plan to allow claimTypes to not only be used to verify an identity but also to verify information about an identity? claimTypes could be used to confirm accreditations from institutions, attendance at events and place of work. So for example if a decentralized Uber was created and this dApp only wanted drivers who had gone to driving school, then claimTypes could be used to confirm this. If the drivers received the proper claimType from a credible driving school they could be drivers for this decentralized application. So claimTypes if used this way could automate the process of checking the credentials of identities. |
|
I understand that you want to keep the contents of the ERC "just the spec" but reading over all of the comments here I think the lack of a really clear problem statement and really clear and targeted solution is causing confusion. It sounds like there are several different interpretations of what this ERC is about in this discussion and everyone has a different image in their head as to what this will be used for. @frozeman Can you provide a problem statement or user story as a starting point? Describe the problem that you are trying to solve (without describing the solution as part of the problem). I just tried to think of an example problem statement that requires this system but was unable to come up with one, which is why I'm struggling to understand the value of this being a standard. An example problem statement for a token standard (pre-ERC20) is:
Note: Be prepared for me to offer alternative solutions to your problem statement that don't involve a standard. 😉 |
|
@jpitts thanks for sharing. URI makes sense, I will change that and also change it for a string for now. @CDsigma your use case it exactly right, you can have people and institutions claiming things about you, and you can allow those claims attached to your identity. And yes; you can never verify an identity if you don’t verify claims about it. @MicahZoltu I agree that it doesn’t seem to catch on right away what the use of this ERC is, though I brought already a few exmpakes which cover your points. But I can try to reformulate:
There are plenty more, and all come down to yourself wanting to prove something in front of others. And the claim model solves that: you can also take a look at https://sovrin.org/wp-content/uploads/2017/06/The-Inevitable-Rise-of-Self-Sovereign-Identity.pdf as they describe a similar system. So in short the solution the ERC brings:
I am not aware of any system, which doesn’t require a central authority that allows to create a self sovereign identity. And I am unclear how this can be solved without a standard. The token standard is quite the same. Everybody could have made their own tokens, but only by creating a standard we are able to use them anywhere, and with erc223 we will be able to have those tokens interact. And as you brought up ERC20 a lot, I assume you are aware that I proposed that standard. Also for this standard, the target is not mainly the UIs, but other identities and smart contracts. Though UIs are as important, to be able to take your identity around. |
|
@frozeman Claim storage: So this will be kind of like a personal registry of claims associated with your identity? If it's only meta data that is being stored on-chain, where would the claim itself be stored? Right now claims are stored off-chain by the users themself in uport. One of the main reason for putting a claim on-chain would be if it needs to be verified by a smart contract. The smart contract is likely to want to know something about a particular account that it is interacting with, rather than the identity itself. Having the claims in a separate registry makes it possible to make claims on any kind of account. Not just this very specific identity contract. This opens upp for the possiblitity of proving something about an account with a zkp without revelaing which identity owns that account. As for your two main reasons for keeping it in the identity contract:
This being said I can see some benefits of putting claims in an identity contract, but for the reasons I stated above I don't think that's the way to go. Btw, you should also check out the work being done on verifiable claims |
|
@oed thanks for the links, that looks very interesting and is very similar to what i am trying to do here as well, but with a purely on chain logic. What i can see every body in this space has come up with, is attributes, or claims and keys as actors. Same as me. Let me try to break down the contract: -> keys: public keys, or other owned smart contract address, which can interact in your name -> execute: A function to allow this identity to act directly on other smart contracts, to be an actor "on-chain", including holding and transfer of ether. -> claims: can be added by others, and verified by others. The claim content is stored off-chain, or onchain, but this is not defined here. Important is that the claim has to a have a proofable piece (which here is the To compare that to the DID, its similar, just that its all in a smart contract and verifiable on chain. To compare that with the W3C verifiable claims, its basically the same, though we can try to align them even more. Also to be clear this is not standardising how claims can look like, how the content is stored, or where. Claims can easily be DDOs for example stored on IPFS. Also how identity verifications are handled off chain, e.g how the message will look like when signing off chain and including your identity address on chain. So there is a lot of defining necessary. This ERC mainly should give a very slick framework to put all those claims and claimtypes and keys inside. Concerning the registry and the identity object (DID vs. DDOs), there can sure be a registry on top which holds the addresses of many identity contracts, e.g. governments could this way group citizens etc. but i don't see a need for that in the basic identity spec. I am open for a call, to discuss that in person, as i see some misconceptions, or i myself have some. |
|
We've been researching and prototyping a solution for identity in the META Network for the last few months and make use of a lot of the same primitives in this proposal and other projects. Our current implementation uses the ENS to register a subdomain to an identity owner's public address, which resolves to a content-addressed object (eg. stored in Swarm, IPFS) where the identity's metadata (or claims) can be retrieved and verified against signatures on that data. This way we utilise an existing standard and minimise what is stored on-chain. Given how much of an essential component identity is to a system or network, it would be great to see a flexible standard that developers could build on - we know first-hand how complex this can be! If it can incorporate/accommodate other efforts (like W3C standards) then all the better. |
|
@lukehedger looking forward to contributions. I just had a fruitful in person discussion with @oed and we came upon with a few small alterations:
It would be really good if work on the holder spec is done first, so that its a good basis, for #725. I will create an issue to discuss this spec part in the coming days. |
|
@frozeman I also think some details are missing regarding the claim (bytes) storage and access. ... Also a question for a better undestanding: Does it mean that if the approve was called by the identity itself or a type 1/2 key, the |
|
@3esmit thanks for you feedback, those are actually good points. I do think separating execute and the get/set data could make sense. As a use case like a digital certificate, which might have data that can be set - the execute function might not be necessary. But doesn't bother either, maybe such virtual asset will need to execute in the future, triggered by its owner?? I assume most assets/accounts will not need have custom erc725 version but use a deployed library contract, which makes the cost roughly 32k gas. So I am a bit torn about separating into multiple standards, as this standard can be used for accounts, items, objects etc. You separation of functions is a good point. i think separating at least In short:
|
|
The problem with using |
|
@frozeman I found out a good way to future proof the universal "execute" interface: For exampl, a minimal ERC725 implementation with this interface: pragma solidity >=0.5.0 <0.6.0;
contract MinimalAccount {
event DataChanged(bytes32 indexed key, bytes value);
event OwnerChanged(address indexed ownerAddress);
address public owner;
mapping(bytes32 => bytes) store;
modifier onlyOwner {
require(msg.sender == address(owner), "Not authorized");
_;
}
modifier self {
require(msg.sender == address(this), "Not authorized");
_;
}
constructor() public {
owner = msg.sender;
}
function execute(
bytes calldata _execData
)
external
onlyOwner
returns (bool success, bytes memory returndata)
{
(success, returndata) = address(this).call(_execData);
}
function call(
address _to,
bytes calldata _data
)
external
self
returns (bool success, bytes memory returndata)
{
(success, returndata) = _to.call(_data);
}
function setData(bytes32 _key, bytes calldata _value)
external
self
{
store[_key] = _value;
emit DataChanged(_key, _value);
}
function changeOwner(address newOwner)
external
self
{
require(newOwner != address(0), "Bad parameter");
owner = newOwner;
emit OwnerChanged(newOwner);
}
function getData(bytes32 _key)
external
view
returns (bytes memory _value)
{
return store[_key];
}
}In this MinimalAccount, only the "call" method is implemented, but its easy to support other types, like delegatedCall, create, create2, approveAndCall, and whatever comes in mind. The In order to wallets list what an proxy account can or cannot perform under execute, ERC165 could be used, but try and gasEstimate error is also a possibility. |
|
The final ERC725 I would suggest to be slim into the needed fields, which are: interface ERC725 {
event DataChanged(bytes32 indexed key, bytes value);
function execute(bytes calldata _execData) external returns (bool success, bytes memory returndata);
function getData(bytes32 _key) external view returns (bytes memory _value);
function setData(bytes32 _key, bytes calldata _value) external;
}I think is interesting to
|
|
I have a different problem with the What I've come up with is this interface: Note that the established execution function is still present. The second execution function can be called not only by the owner but by anyone. However, the calling party is required to produce a signature over the following structure: This signature can only be generated by the owner. But being able to generate it does not require controlling a funded address. Therefore (along with a constructor allowing to set the owner explicitly), it is possible to have an identity contract that is fully controlled by an unfunded address. Note that the signed structure includes a nonce. This is to eliminate replay attacks. Furthermore, it contains the identity contract's address to foil attacks where the attacker replays transactions previously issued via a different identity contract with the same owner. As @3esmit's proposal has not yet been commented on by @frozeman, I built my proposal on the execution function stated in the opening post. However, my proposal can easily be modified to be compatible with his. |
|
Thanks guys for the write up. I was incredible busy and still am, due to the Reversible ICO that just started for LUKSO. This standard is instrumental for LUKSO, so I am very interested in finalizing it. Here my short comments (longer will follow when I have more time) @m1cm1c it’s a good idea, but I am not sure if it should be part of this standard, as my idea here was that any permission system, or relay system could be added to the owner smart contract and this way be upgradable. |
|
Hello @frozeman! We are considering using the ERC-725 for the proxy account used in the GSN. The GSN is a comprehensive modular meta-transactions network you can read about the previous version here and about the upcoming version 2.0 on our website This is an almost 3 years long discussion here so I would be grateful if you could help me find up-to-date answers to a few questions to see if the proposed standard is a good choice for us. I hope we can prevent the creation of yet another Proxy Account EIP, and thank you for you time in advance :-)
|
|
Hey @forshtat happy to hear that you are considering this. To your questions:
Reach out to me on telegram @frozeman, and we can discuss your ideas. |
|
Also @forshtat feel free to join the LUKSO discord as we are discussing 725 there in the standards channel: https://discord.gg/E2rJPP4 |
|
As I realize that were have sometime different understandings of what this ERC tries to achieve, i added a list to the motivation section: The smart contract account SHOULD be:
|
|
After implementing this standard for two uses cases: LUKSOs digital certificates (NFT2.0) and LUKSO smart contract based accounts, I think it is necessary to split this standard in two. I think this will be a very welcome change, as now both can be used individually without confusion. UPDATED edited to reflect the addition of ERC173
event ContractCreated(address indexed contractAddress);
function execute(uint256 _operationType, address _to, uint256 _value, bytes memory data) external;
event DataChanged(bytes32 indexed key, bytes value);
function getData(bytes32 key) external view returns (bytes memory value);
function setData(bytes32 key, bytes memory value) external;
Any contract can either implement |
|
Two proposals to dicusss:
|
|
I just discovered https://eips.ethereum.org/EIPS/eip-173, it makes obviously sense that ERC725 uses ERC173. interface ERC173 /* is ERC165 */ {
event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);
function owner() view external;
function transferOwnership(address _newOwner) external;
}A full ERC725 then is made up of: |
|
One addition to bytes32[] public storeKeys;
function storeCount() public view returns (uint256) {
return storeKeys.length;
}
// the setData will also store the keys in the `storeKeys array`As this would make it easily possible for an interface to list all key value pairs easily. |
|
The top issues is updated and lates implementation can be found here: |
|
What are thoughts about an |
|
The data key for keys with multiple elements was changed to: This would looks as follows for `ERCXXXMyNewKeyType[]` (keccak256: `0x4f876465dbe22c8495f4e4f823d846957ddb8ce6006afe66ddc5bac4f0626767`):
- element number: key: `0x4f876465dbe22c8495f4e4f823d846957ddb8ce6006afe66ddc5bac4f0626767`, value: `0x0000000000000000000000000000000000000000000000000000000000000002` (2 elements)
- element 1: key: `0x4f876465dbe22c8495f4e4f823d8469500000000000000000000000000000000`, value: `0x123...` (element 0)
- element 2: key: `0x4f876465dbe22c8495f4e4f823d8469500000000000000000000000000000001`, value: `0x321...` (element 1)
... |
|
The first erc725 package BETA is released: |
Was the idea meant to allow calling other contracts who have added |
|
Note: I changed the proposed key |
|
There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
|
@frozeman Hi Fabian. What is the current status of the ERC725 tokens? Are they even used today? Asking also because of the recent Soulbound Tokens (SBTs) "hype". Thank you very much! |
|
ERC-725 is still a draft, and should not be used in production applications: https://eips.ethereum.org/EIPS/eip-725 |
and others
This proposal has moved to ERC-725 (source).
This issue exists as an archive only.
Original Text
This is the new 725 v2 standard, that is radically different from ERC 725 v1. ERC 725 v1 is be moved to #734 as a new key manager standard.
Simple Summary
A standard interface for a smart contract based account with attachable key value store.
Abstract
The following describes standard functions for a unique smart contract based account that can be used by humans,
groups, organisations, objects and machines.
The standard is divided into two sub standards:
ERC725X:Can execute arbitrary smart contracts using and deploy other smart contracts.
ERC725Y:Can hold arbitrary data through a generic key/value store.
Motivation
Standardizing a minimal interface for a smart contract based account allows any interface to operate through these account types.
Smart contact based accounts following this standard have the following advantages:
Specification
ERC725X
ERC165 identifier:
0x44c028feexecute
Executes a call on any other smart contracts, transfers the blockchains native token, or deploys a new smart contract.
MUST only be called by the current owner of the contract.
The
operationTypecan execute the following operations:0forcall1fordelegatecall2forcreate23forcreateOthers may be added in the future.
Triggers Event: ContractCreated if a contract was created
Events
ContractCreated
MUST be triggered when
executecreates a new contract using the_operationType1.ERC725Y
ERC165 identifier:
0x2bd57b73getData
Returns the data at the specified key.
setData
Sets the data at a specific key. MUST only be called by the current owner of the contract.
Triggers Event: DataChanged
Events
DataChanged
MUST be triggered when
setDatawas successfully called.Ownership
This contract is controlled by an owner. The owner can be a smart contract or an external account.
This standard requires ERC173 and should implement the functions:
owner() viewtransferOwnership(address newOwner)event OwnershipTransferred(address indexed previousOwner, address indexed newOwner)Data keys
Data keys, should be the keccak256 hash of a type name.
e.g.
keccak256('ERCXXXMyNewKeyType')is0x6935a24ea384927f250ee0b954ed498cd9203fc5d2bf95c735e52e6ca675e047Multiple keys of the same type
If you require multiple keys of the same key type they MUST be defined as follows:
[]add and then hashedFor all other elements:
uint128of the number of the element0Example
This would looks as follows for
ERCXXXMyNewKeyType[](keccak256:0x4f876465dbe22c8495f4e4f823d846957ddb8ce6006afe66ddc5bac4f0626767):0x4f876465dbe22c8495f4e4f823d846957ddb8ce6006afe66ddc5bac4f0626767, value:0x0000000000000000000000000000000000000000000000000000000000000002(2 elements)0x4f876465dbe22c8495f4e4f823d8469500000000000000000000000000000000, value:0x123...(element 0)0x4f876465dbe22c8495f4e4f823d8469500000000000000000000000000000001, value:0x321...(element 1)...
Default key values
ERC725 key standards need to be defined within new standards, we suggest the following defaults:
0xeafec4d89fa9619884b6b89135626455000000000000000000000000xxxxxxxx, wherexxxxxxxxis the 4 bytes identifier of the standard supported0x7a30e6fc0xeafec4d89fa9619884b6b89135626455000000000000000000000000afdeb5d6, whereafdeb5d6is the 4 bytes part of the hash ofkeccak256('ERC725Account')0xafdeb5d6ERC725Account
An ERC725Account is an ERC725 smart contract based account for storing of assets and execution of other smart contracts.
ERC173to be controllable by an owner, that could be am external account, or smart contractERC725Xto interact with other smart contractsERC725Yto attach data to the account for future extensibilityERC1271to be able to verify signatures from owners.event ValueReceived(address indexed sender, uint256 indexed value)if ETH is received.A full implementation of an
ERC725Accountcan be found found here.Rationale
The purpose of an smart contract account is to allow an entity to exist as a first-class citizen with the ability to execute arbitrary contract calls.
Implementation
Solidity Interfaces
Flow chart
Additional References
Copyright
Copyright and related rights waived via CC0.
The text was updated successfully, but these errors were encountered: