ethereum/EIPs-725

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-725.md

eip title author discussions-to status type category created

725

Proxy Identity

Fabian Vogelsteller (@frozeman)

https://github.com/ethereum/EIPs/issues/725

Draft

Standards Track

ERC

2017-10-02

Simple Summary

Proxy contract for key management and execution, to establish a Blockchain identity.

代理合约是通过建立区块链身份来实现密钥的管理和执行的

Abstract

The following describes standard functions for a unique identity for humans, groups, objects and machines. 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 (#ERC735), as well as a proxy function to act directly on the blockchain.

下面描述了给予人、组、物体、机器唯一身份的标准函数的实现。这个身份可以管控密钥来签名所做的操作;claims是通过第三方(发行商)和自己来进行证明的。代理函数是直接在区块链上操作的。

Motivation

This standardised identity interface will allow Dapps, smart contracts and thirdparties to check the validity of a person, organisation, object or machine through 2 steps as described in the function XXX. Trust is here transfered to the issuers of claims.

就是通过调用身份接口来证明这些人、组、物体、机器的有效性,通过以下两步进行:

The most important functions to verify an identity are: XXX

The most important functions to manage an identity are: XXX

Definitions

  • keys: Keys are public keys from either external accounts, or contract addresses.来自外部账户或合约账户的公钥
  • claim issuer: is another smart contract or external account, which issues claims about this identity. The claim issuer can be an identity contract itself.身份发行商
  • claim: For details about claims 身份  see #ERC735

Specification

Key Management

Keys are cryptographic public keys, or contract addresses associated with this identity. The structure should be as follows:

keys就是加密后的公钥(当为EOA账户时)或者与这个身份相关的合约地址

  • key: A public key owned by this identity

    • purposeuint256[] Array of the key types, like 1 = MANAGEMENT, 2 = ACTION, 3 = CLAIM, 4 = ENCRYPTION,这个key的作用是什么,下面有解释
    • keyType: The type of key used, which would be a uint256 for different key types. e.g. 1 = ECDSA, 2 = RSA, etc.key使用的加密方法
    • keybytes32 The public key. // for non-hex and long keys, its the Keccak256 hash of the key
struct Key {
    uint256[] purposes;
    uint256 keyType;
    bytes32 key;
}

getKey

Returns the full key data, if present in the identity.

function getKey(bytes32 _key) constant returns(uint256[] purposes, uint256 keyType, bytes32 key);

keyHasPurpose

Returns the TRUE if a key has is present and has the given purpose. If key is not present it returns FALSE.

function keyHasPurpose(bytes32 _key, uint256 purpose) constant returns(bool exists);

getKeysByPurpose

Returns an array of public key bytes32 hold by this identity.

function getKeysByPurpose(uint256 _purpose) constant returns(bytes32[] keys);

addKey

Adds a _key to the identity. The _purpose specifies the purpose of key. Initially we propose four purposes:

key的作用

  • 1: MANAGEMENT keys, which can manage the identity,用来管理身份
  • 2: ACTION keys, which perform actions in this identities name (signing, logins, transactions, etc.)在这个身份下执行操作
  • 3: CLAIM signer keys, used to sign claims on other identities which need to be revokable.用来在别的身份上签署claims,这个身份是可以取消的
  • 4: ENCRYPTION keys, used to encrypt data e.g. hold in claims.用来加密数据

MUST only be done by keys of purpose 1, or the identity itself. If its the identity itself, the approval process will determine its approval.

Triggers Event: KeyAdded

function addKey(bytes32 _key, uint256 _purpose, uint256 _keyType) returns (bool success)

removeKey

Removes _key from the identity.

MUST only be done by keys of purpose 1(即MANAGEMENT), or the identity itself. If its the identity itself, the approval process will determine its approval.

Triggers Event: KeyRemoved

function removeKey(bytes32 _key, uint256 _purpose) returns (bool success)

Identity usage身份的使用

execute

Executes an action on other contracts, or itself, or a transfer of ether. SHOULD require approve to be called with one or more keys of purpose 1(MANAGEMENT) or 2 (ACTION)to approve this execution.执行对其他合约、合约本身或eth的转让的操作。应该通过调用包含一个或多个实现目的1(管理)或2(动作)key的approve去批准执行。

Execute COULD be used as the only accessors for addKeyremoveKey and replaceKey and removeClaim.

Execute可以作为addKey、removeKey和replaceKey以及removeClaim的唯一途径

Returns executionId: SHOULD be send to the approve function, to approve or reject this execution.
返回executionId:应该发送到approve函数,以批准或拒绝此执行。

Triggers Event: ExecutionRequested Triggers on direct execution Event: Executed

function execute(address _to, uint256 _value, bytes _data) returns (uint256 executionId)

approve

Approves an execution or claim addition. This SHOULD require n of m approvals of keys purpose 1, if the _to of the execution is the identity contract itself, to successfull approve an execution. And COULD require n of m approvals of keys purpose 2, if the _to of the execution is another contract, to successfull approve an execution.

批准执行或添加有关身份的claim。如果执行的_to是identity合约本身,那么要成功地批准执行,应该需要m个目的1(管理)密钥中n个的批准。如果执行的_to是另一个合约,则可能需要m个目的2(动作)密钥中n个的批准才能成功地批准执行。

Triggers Event: Approved Triggers on successfull execution Event: Executed Triggers on successfull claim addition Event: ClaimAdded

function approve(uint256 _id, bool _approve) returns (bool success)

Identity verification

Requires: ERC 735

The following changes to ERC 735 are REQUIRED:

addClaim

This SHOULD create a pending claim, which SHOULD to be approved or rejected by n of m approve calls from keys of purpose 1.创建一个待定的claim,应该需要m个目的1(管理)密钥中n个的批准

Only Events: Triggers if the claim is new Event and approval process exists: ClaimRequested Triggers if the claim index existed Event: ClaimChanged

removeClaim

MUST only be done by the issuer of the claim, or keys of purpose 1, or the identity itself. If its the identity itself, the approval process will determine its approval.

只有claim发行商、目的一的密钥或身份本身能执行。如果是身份本身,审批过程将决定其审批。

问题:key,claim,identity之间的关系到底是什么,看本博客ERC 725 and ERC 735 的实现及关系

Events

KeyAdded

MUST be triggered when addKey was successfully called.

event KeyAdded(bytes32 indexed key, uint256 indexed purpose, uint256 indexed keyType)

KeyRemoved

MUST be triggered when removeKey was successfully called.

event KeyRemoved(bytes32 indexed key, uint256 indexed purpose, uint256 indexed keyType)

ExecutionRequested

MUST be triggered when execute was successfully called.

event ExecutionRequested(uint256 indexed executionId, address indexed to, uint256 indexed value, bytes data)

Executed

MUST be triggered when approve was called and the execution was successfully approved.

event Executed(uint256 indexed executionId, address indexed to, uint256 indexed value, bytes data)

Approved

MUST be triggered when approve was successfully called.

event Approved(uint256 indexed executionId, bool approved)
The following changes to ERC 735 are REQUIRED:

ClaimRequested

MUST be triggered when addClaim was successfully called.

ClaimAdded

MUST be triggered when approve was called and the claim was successfully added.

Constraints

  • A claim can only be one type per type per issuer.对于每个发行者,每个类型的claim只能是一种类型

Implementation

Solidity Interface

pragma solidity ^0.4.18;

contract ERC725 {

    uint256 constant MANAGEMENT_KEY = 1;
    uint256 constant ACTION_KEY = 2;
    uint256 constant CLAIM_SIGNER_KEY = 3;
    uint256 constant ENCRYPTION_KEY = 4;

    event KeyAdded(bytes32 indexed key, uint256 indexed purpose, uint256 indexed keyType);
    event KeyRemoved(bytes32 indexed key, uint256 indexed purpose, uint256 indexed keyType);
    event ExecutionRequested(uint256 indexed executionId, address indexed to, uint256 indexed value, bytes data);
    event Executed(uint256 indexed executionId, address indexed to, uint256 indexed value, bytes data);
    event Approved(uint256 indexed executionId, bool approved);

    struct Key {
        uint256 purpose; //e.g., MANAGEMENT_KEY = 1, ACTION_KEY = 2, etc.
        uint256 keyType; // e.g. 1 = ECDSA, 2 = RSA, etc.
        bytes32 key;
    }

    function getKey(bytes32 _key) public constant returns(uint256[] purposes, uint256 keyType, bytes32 key);
    function keyHasPurpose(bytes32 _key, uint256 _purpose) public constant returns (bool exists);
    function getKeysByPurpose(uint256 _purpose) public constant returns (bytes32[] keys);
    function addKey(bytes32 _key, uint256 _purpose, uint256 _keyType) public returns (bool success);
    function removeKey(bytes32 _key, uint256 _purpose) public returns (bool success);
    function execute(address _to, uint256 _value, bytes _data) public returns (uint256 executionId);
    function approve(uint256 _id, bool _approve) public returns (bool success);
}

原文地址:https://www.cnblogs.com/wanghui-garcia/p/9636817.html

时间: 2024-08-02 09:37:55

ethereum/EIPs-725的相关文章

【Ethereum】以太坊ERC20 Token标准完整说明

什么是ERC20 token 市面上出现了大量的用ETH做的代币,他们都遵守REC20协议,那么我们需要知道什么是REC20协议. 概述 token代表数字资产,具有价值,但是并不是都符合特定的规范. 基于ERC20的货币更容易互换,并且能够在Dapps上相同的工作. 新的标准可以让token更兼容,允许其他功能,包括投票标记化.操作更像一个投票操作 Token的持有人可以完全控制资产,遵守ERC20的token可以跟踪任何人在任何时间拥有多少token.基于eth合约的子货币,所以容易实施.只

ethereum/EIPs-55 Mixed-case checksum address encoding

eip title author type category status created 55 Mixed-case checksum address encoding Vitalik Buterin Standards Track ERC Final 2016-01-14 Specification(python) from ethereum import utils def checksum_encode(addr): # Takes a 20-byte binary address as

ERC: Claim Holder #735 status:Discussion

EIP: 735 Title: Claim Holder Author: Fabian Vogelsteller (@frozeman) Type: Standard Category: ERC Status: Discussion Created: 2017-10-09 https://github.com/ethereum/EIPs/issues/735 Abstract The following describes standard functions for adding, remov

PoW挖矿算法原理及其在比特币、以太坊中的实现

PoW,全称Proof of Work,即工作量证明,又称挖矿.大部分公有链或虚拟货币,如比特币.以太坊,均基于PoW算法,来实现其共识机制.即根据挖矿贡献的有效工作,来决定货币的分配.? 比特币区块 ? 比特币区块由区块头和该区块所包含的交易列表组成.区块头大小为80字节,其构成包括:? 4字节:版本号 32字节:上一个区块的哈希值 32字节:交易列表的Merkle根哈希值 4字节:当前时间戳 4字节:当前难度值 4字节:随机数Nonce值? 此80字节长度的区块头,即为比特币Pow算法的输入

以太坊源码机制:挖矿

狗年吉祥,开工利是,我们继续研究以太坊源码.从本篇文章开始,我们会深入到以太坊核心源码中去,进而分析与研究以太坊的核心技术. 关键字:拜占庭,挖矿,矿工,分叉,源码分析,uncle叔块,agent,worker,事件监听 本文基于go-ethereum 1.7.3-stable源码版本.源码范围主要在miner pkg. miner.start() miner即矿工的意思,矿工要做的工作就是"挖矿",挖矿就是将一系列最新未封装到块中的交易封装到一个新的区块的过程.学习以太坊挖矿之前,我

剖析非同质化代币ERC721-全面解析ERC721标准

什么是ERC-721?现在我们看到的各种加密猫猫狗狗都是基于ERC-721创造出来的,每只都是一个独一无二的ERC-721代币,不过ERC-721在区块链世界远不止猫猫狗狗,它更大的想象空间在于将物理世界的资产映射到区块链上.本文就来剖析下什么是ERC721. ERC721是什么 在创建代币一篇,我们讲到过ERC20代币,和ERC20一样,ERC721同样是一个代币标准,ERC721官方简要解释是Non-Fungible Tokens,简写为NFTs,多翻译为非同质代币. ERC721 是由Di

以太坊智能合约项目-Token合约开发与部署

修订日期 姓名 邮箱 2019-09-05 brucefeng [email protected] 一. 钱包环境安装 以太坊钱包顾名思义,就是管理以太坊地址,存储以太坊Token的工具,再简单点说,任何区块链网络都需要我们有自己的账户,管理账户的软件可称之为钱包,无论是炒币的还是研究以太坊开发的,钱包都是必不可少的. 1.钱包分类 1.1 Mist 说到以太坊钱包,第一个要说的当然就是Ethereum官方钱包+浏览器 Mist.Mist是一个全节点钱包(全节点钱包通俗的来说就是同步了全部的以太

第19讲 | 上手搭建一条自己的智能合约

上一篇我们聊到了区块链智能合约,我主要介绍了智能合约的概念,但是并没有给你提供智能合约的实际运行案例,那么今天,我们就自己动手写一个智能合约,并且介绍一下智能合约标准模板,供你参考学习, 并搭建起自己的智能合约. 本篇将以以太坊作为基础知识进行讲解,本篇面向没有任何智能合约基础的人群,所以配备了较多的插图和操作命令,如果你正在收听音频,可以点击文稿查看,希望读完这篇文章可以帮助你快速入门智能合约. 搭建一条智能合约 在实际操作智能合约之前,我们首先回顾一下以太坊,以太坊又称以太坊钱包.以太坊钱包

rpc接口调用以太坊智能合约

rpc接口调用以太坊智能合约 传送门: 柏链项目学院 ??在以太坊摸爬滚打有些日子了,也遇到了各种各样的问题.这几天主要研究了一下如何通过rpc接口编译.部署和调用合约.也遇到了一些困难和问题,下面将向大家分享. rpc接口调用智能合约 先来编写一个简单的智能合约 contract Multiply7 { event Print(uint); function multiply(uint input) returns (uint) { Print(input * 7); return input