profile
viewpoint
Kevin Simper kevinsimper Blackbeard Copenhagen, Denmark https://www.kevinsimper.dk Working on electric car sharing at @greenmobility

chklueter/code-of-conduct 1

Code of conduct for HackYourFuture Copenhagen

HackYourFuture-CPH/teaching-instructions 1

Step-by-step guide for new (and old) teachers

kevinsimper/berglas 1

A tool for managing secrets on Google Cloud

copenhagenjs/meetup-slides 0

The welcome presentations from each month meetups.

inga-balcune/countries-of-the-world 0

Countries of the World is my first serious front end web development project and first repository on Github

kevinsimper/aenea 0

Client-server library for using voice macros from Dragon NaturallySpeaking and Dragonfly on remote/non-windows hosts.

kevinsimper/akasse 0

Info om akasser

kevinsimper/alpine-caddy 0

Alpine Linux Docker Container running Caddyserver

create barnchethereum/eth2.0-specs

branch : block-slot-fork-choice

created branch time in an hour

issue commentethereum/EIPs

Etc

Since this is your first issue, we kindly remind you to check out EIP-1 for guidance.

gmoneydummy

comment created time in 6 hours

issue openedethereum/EIPs

Etc

ATTENTION! If you would like to submit an EIP and it has already been written as a draft (see the template for an example), please submit it as a Pull Request.

If you are considering a proposal but would like to get some feedback on the idea before submitting a draft, then continue opening an Issue as a thread for discussion. Note that the more clearly and completely you state your idea the higher the quality of the feedback you are likely to receive.

Keep in mind the following guidelines from EIP-1:

Each EIP must have a champion - someone who writes the EIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The EIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is EIP-able. Posting to the the Protocol Discussion forum or opening an Issue is the best way to go about this.

Vetting an idea publicly before going as far as writing a EIP is meant to save the potential author time. Asking the Ethereum community first if an idea is original helps prevent too much time being spent on something that is guaranteed to be rejected based on prior discussions (searching the Internet does not always do the trick). It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will work for most people in most areas where Ethereum is used.

Once the champion has asked the Ethereum community as to whether an idea has any chance of acceptance, a draft EIP should be presented as a Pull Request. This gives the author a chance to flesh out the draft EIP to make properly formatted, of high quality, and to address initial concerns about the proposal.

created time in 6 hours

issue openedapex/up

apex/apex Releases Removed?

Description

Hi, the archival of the apex/apex repo made it a breaking change rather than a gradual deprecation.

The install script curl https://raw.githubusercontent.com/apex/apex/master/install.sh | sh no longer works, because the .tar.gz files and the releases API page the script is trying to access are both broken.

Can the releases page be restored so projects can at least keep using the repo? The usage of the install script is necessary for us to use in our CI/CD pipeline.

Alternatively, could the latest version of the MacOS/Linux binary at least be made available in the binary so we can download and host it ourselves? I see no way to access the latest binary from that repo's home page: https://github.com/apex/apex .

created time in 7 hours

PR closed ethereum/EIPs

Update and rename CNAME to CNAME MIST BROWSER

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
+3 -1

1 comment

2 changed files

hurtadodayna

pr closed time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:

This EIP cannot be merged until this is fulfilled.

weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>+replaces (*optional): <EIP number(s)>+---++## Simple Summary++Today chainid definition as specified in EIP-155 is an integer type.  This is not unique enough to identify all public and private blockchains.  A blockchain identifier (crosschain id) should be unique and satisfy the following requirements:++should provide identification, description, and discovery of blockchains.+should provide unique identification of each blockchain in the crosschain service ecosystem.+should provide descriptions for a blockchain identities such as chainId, name, type, consensus scheme etc.+should provide discovery mechanism for supported blockchains and also for new blockchains in the ecosystem.+should provide a mechanism for a joining blockchain to register to the ecosystem.+should provide a mechanism for a blockchain to edit properties or unregister from the crosschain ecosystem.+should provide a mechanism to get some critical information of the blockchain+should provide a mechanism to differentiate an original blockchain and a forked blockchain+should provide a mechanism to verify a chainid without external registration service++Hence we provide a specification for using a 32 byte identifier to represent any blockchain.  We call this identifier crosschain-id.++## Abstract++A short (~200 word) description of the technical issue being addressed.++Crosschain operations include transfer of assets, data, message, events, and commands from one blockchain to another. In order to improve interoperability of crosschain operations, there is a need to uniquely identify source blockchain, target blockchains, and any relay chains that help facilite blockchain information tranfer.  The identifier should follow a standard format so that all platforms and decentralize applications can use this identifier to represent a blockchain and also some information in the identifier to get some characteristis of the blockchain.  We name this blockchain identifier as crosschain-id and expect Ethereum community to use crosschain-id to represent any public or private blockchain.  The crosschain-id is a 32 byte hex string and with some bytes extracted from blockchain hash and some manually defined to characterize a blockchain.  We also propose a registration and lookup service to retrieve blockchain metadata from the crosschain-id.++## Motivation++EIP-155 was proposed by Vitalik to provide a unique identifier to a blockchain to provide simple relay attack protection.  This specification defines an integer for Chainid for a blockchain and sign the chainid into a transaction data and hence present attackers to send same transaction to different blockchains. This specification will require blockchains to define a chainid and register the chainid in a public repository.++The challenge of using an integer for chainid is that it is not broad enough to cover all blockchains and it does not prevent different blockchains using the same chainid.  Also, it does not address the issue for two forked blockchains having the same chainid.++Hence there is need for a more robust blockchain identifier that will overcome these drawbacks, especially for crosschain operations where multiple chains are involved.++## Specification++The section specifies a) The crosschain id definition b) the registration smart contract the defines metadata to be associated with a crosschain id; and c) the basic functions to parse and process a crosschain id.++### Definition of a 32 byte crosschain id++| Name          | Size(bytes) | Description |+|---------------|-------------|-------------|+| Truncated Block Hash | 16 | This is the block hash of the genesis block or the block hash of of the block immediate prior to the fork for a fork of a blockchain. The 16 bytes is the 16 least significant bytes, assuming network byte order. See table XYZA below for a list of existing blockchains. |+|Native Chain ID| 4 | This is the **Chain Id** value that should be used with the blockchain when signing transactions. For blockchains that do not have a concept of **Chain Id**, this value is zero.|+|Chain Type| 2 |  See table XYZ below the current list of chain types. |+| Governance Identifier | 2 |  For new blockchains, a governance_identifier can be specified to identify an original **owner** of a blockchain, to help settle forked / main chain disputes. For all existing blockchains and for blockchains that do not have the concept of an **owner**, this field is zero. |+| Reserved | 7 | Reserved for future use. Use 000000 for now. |+| Checksum | 1 | Used to verify the integrity of the identifier. This integrity check is targetted at detecting Crosschain Identifiers mis-typed by human users. The value is calculated as the truncated SHA256 message digest of the rest of the identifier, using the least significant byte, assuming network byte order. Note that this checksum byte only detects integrity with a probability of one in 256. This probability is adequate for the intended usage of detecting typographical errors by people manually entering the Crosschain Identifier. |++### Definition of crosschain id registration smart contract++The crosschain registration smart contract provides a registration service to crosschain id and its associated meta data.  The smart contract should support the following meta data.++|Metadata Name| Description  | Examples|+|-------------|--------------|---------|+|Crosschain Id|32 byte hex id|0xabc. See the crosschain id section for details|+|Long Name|A long naname describing the blockchain.  Maximum length is 80 characters.|This long name could be **Ethereum Mainnet**, **Bitcoin Cash**, **Wanchain Mainnet** etc|+|Short Name|An abbreviated name for the blockchain. Maximum length is four characters.|For public blockchains, this will match the standard blockchain exchange name. For example, **ETC**, **BTC**, or **WAN**.|+|Nickname|Nickname of the chain. Maximum length is 10 characters.|Names such as **Rinkeby** or **Ropsten**.|+|Chain Type|A meta data for the type of the blockchains such as public or private, permissioned or permissionless| Private:permissioned|+|Chain Category|A parameter to identify whether this is mainnet, or testnet|"mainnet", "testnet"|+|Chain IP addresses and Service Provider Id|A set of IP addresses of static nodes that can be contacted to submit a crosschain transaction, and the associated name information for the company providing the service.|125.125.125.125, 10.10.20.20|+|Name Service Type|The contract naming service available on the blockchain.|The type of service, for instance **ENS**.|+|Name Service Address|The address of the name service contract on the blockchain.| |++### Crosshchain Identifier Registration Contract++To register crosschian/blockchain id, there should be grace period for comments before it become official and verified.  The registration service should support the following functions++* RegisterBlockchainId+* ModifyName+* ModifyParameters+* VerifyBlockchainId+* QueryBlockChainId+* LookupBlockchainId+* QueryBlockchainOwner+* QueryBlockchainName(Blockchain-id, NameType)+* QueryParentBlockchainId++## Rationale++The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.+With the success of Bitcoin and Ethereum, various blockchains such as EOS, Ripple, Litecoin, Besu, Wanchain and the like have been developed and are growing at a fast pace.  There are also other private and consortium blockchains such as Hyperledger Fabric, Hyperledger Besu, Stellar, Corda, Quorum that only allow nodes with permitted identities to join the blockchain network.  The growth of public and private blockchains imposes+challenges for inter-chain interoperability, particularly when these chains are+heterogeneous and incompatible.+Enterprise Ethereum Alliance formed Crosschain Interoperability Task Force (CITF) to look into common crosschain problems and solutions. CITF team noticed that there is a lack of unique identifier to charaterise and describe a blockchain. Several proprosals were discussed in EEA Crosschain Interoperability Task Force meetings and discussions.  We have considered various alternative specifications such as using a random unique hex string to represent a blockchain.  The drawback of this method is that the random id can not be used to verify a blockchain's intrinsic identity such as the blockhash of the genesis block.  A second alternative is simply using a genesis blockhash to represent a blockchain id for crosschain operations.  The drawback of this is that this id does not have information about the property of the blockchain and it has problem when a blockchain is forked into two blockchain.  After various discussion, we finally came up with hybrid crosschain identity specification that allows a blockchain to be identified and verified both manually and through computer programs.++## Backwards Compatibility++Crosschainid can be backward compatible with EIP-155.  The crosschain id contains a 4 byte segment to record the chainid based on EIP-155.++## Test Cases++The test cases should cover the generation of crosschain id, the parsing of an crosschain id to ensure the various segments of the crosschain id meets the specification.+For the crosschain registration smart contract, the test cases should cover the testing of all functions and also need to ensure that the security of each functions are properly implemented.++## Implementation++The implementation requires the following++* Generate the crosschain id based on the format defined in the specification.  +* Parse the crosschain id based on the format defined in the spefication.+* For metadata asssociated with the crosschainid, the medadata needs to be registered with a smart contract.  The smart contract should implement the functions defined in the speficification.+* Once a smart contract is deployed, the owner of the smart contract can publish the smart contract address, ABI and also crosschain id specification version.+* Once a crosschain id is registered in the smart contract with extended metadata, there should be a waiting period for the community to review the registration and raise objection if there is inconsistency.++## Security Considerations

There are few formatting ideas in this section, it would be best to choose one format and stick with it. For example:

problem: solution
or
#### problem
solution
weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>+replaces (*optional): <EIP number(s)>+---++## Simple Summary++Today chainid definition as specified in EIP-155 is an integer type.  This is not unique enough to identify all public and private blockchains.  A blockchain identifier (crosschain id) should be unique and satisfy the following requirements:++should provide identification, description, and discovery of blockchains.+should provide unique identification of each blockchain in the crosschain service ecosystem.+should provide descriptions for a blockchain identities such as chainId, name, type, consensus scheme etc.+should provide discovery mechanism for supported blockchains and also for new blockchains in the ecosystem.+should provide a mechanism for a joining blockchain to register to the ecosystem.+should provide a mechanism for a blockchain to edit properties or unregister from the crosschain ecosystem.+should provide a mechanism to get some critical information of the blockchain+should provide a mechanism to differentiate an original blockchain and a forked blockchain+should provide a mechanism to verify a chainid without external registration service++Hence we provide a specification for using a 32 byte identifier to represent any blockchain.  We call this identifier crosschain-id.++## Abstract++A short (~200 word) description of the technical issue being addressed.++Crosschain operations include transfer of assets, data, message, events, and commands from one blockchain to another. In order to improve interoperability of crosschain operations, there is a need to uniquely identify source blockchain, target blockchains, and any relay chains that help facilite blockchain information tranfer.  The identifier should follow a standard format so that all platforms and decentralize applications can use this identifier to represent a blockchain and also some information in the identifier to get some characteristis of the blockchain.  We name this blockchain identifier as crosschain-id and expect Ethereum community to use crosschain-id to represent any public or private blockchain.  The crosschain-id is a 32 byte hex string and with some bytes extracted from blockchain hash and some manually defined to characterize a blockchain.  We also propose a registration and lookup service to retrieve blockchain metadata from the crosschain-id.++## Motivation++EIP-155 was proposed by Vitalik to provide a unique identifier to a blockchain to provide simple relay attack protection.  This specification defines an integer for Chainid for a blockchain and sign the chainid into a transaction data and hence present attackers to send same transaction to different blockchains. This specification will require blockchains to define a chainid and register the chainid in a public repository.++The challenge of using an integer for chainid is that it is not broad enough to cover all blockchains and it does not prevent different blockchains using the same chainid.  Also, it does not address the issue for two forked blockchains having the same chainid.++Hence there is need for a more robust blockchain identifier that will overcome these drawbacks, especially for crosschain operations where multiple chains are involved.++## Specification++The section specifies a) The crosschain id definition b) the registration smart contract the defines metadata to be associated with a crosschain id; and c) the basic functions to parse and process a crosschain id.++### Definition of a 32 byte crosschain id++| Name          | Size(bytes) | Description |+|---------------|-------------|-------------|+| Truncated Block Hash | 16 | This is the block hash of the genesis block or the block hash of of the block immediate prior to the fork for a fork of a blockchain. The 16 bytes is the 16 least significant bytes, assuming network byte order. See table XYZA below for a list of existing blockchains. |+|Native Chain ID| 4 | This is the **Chain Id** value that should be used with the blockchain when signing transactions. For blockchains that do not have a concept of **Chain Id**, this value is zero.|+|Chain Type| 2 |  See table XYZ below the current list of chain types. |+| Governance Identifier | 2 |  For new blockchains, a governance_identifier can be specified to identify an original **owner** of a blockchain, to help settle forked / main chain disputes. For all existing blockchains and for blockchains that do not have the concept of an **owner**, this field is zero. |+| Reserved | 7 | Reserved for future use. Use 000000 for now. |+| Checksum | 1 | Used to verify the integrity of the identifier. This integrity check is targetted at detecting Crosschain Identifiers mis-typed by human users. The value is calculated as the truncated SHA256 message digest of the rest of the identifier, using the least significant byte, assuming network byte order. Note that this checksum byte only detects integrity with a probability of one in 256. This probability is adequate for the intended usage of detecting typographical errors by people manually entering the Crosschain Identifier. |++### Definition of crosschain id registration smart contract++The crosschain registration smart contract provides a registration service to crosschain id and its associated meta data.  The smart contract should support the following meta data.++|Metadata Name| Description  | Examples|+|-------------|--------------|---------|+|Crosschain Id|32 byte hex id|0xabc. See the crosschain id section for details|+|Long Name|A long naname describing the blockchain.  Maximum length is 80 characters.|This long name could be **Ethereum Mainnet**, **Bitcoin Cash**, **Wanchain Mainnet** etc|+|Short Name|An abbreviated name for the blockchain. Maximum length is four characters.|For public blockchains, this will match the standard blockchain exchange name. For example, **ETC**, **BTC**, or **WAN**.|+|Nickname|Nickname of the chain. Maximum length is 10 characters.|Names such as **Rinkeby** or **Ropsten**.|+|Chain Type|A meta data for the type of the blockchains such as public or private, permissioned or permissionless| Private:permissioned|+|Chain Category|A parameter to identify whether this is mainnet, or testnet|"mainnet", "testnet"|+|Chain IP addresses and Service Provider Id|A set of IP addresses of static nodes that can be contacted to submit a crosschain transaction, and the associated name information for the company providing the service.|125.125.125.125, 10.10.20.20|+|Name Service Type|The contract naming service available on the blockchain.|The type of service, for instance **ENS**.|+|Name Service Address|The address of the name service contract on the blockchain.| |++### Crosshchain Identifier Registration Contract++To register crosschian/blockchain id, there should be grace period for comments before it become official and verified.  The registration service should support the following functions++* RegisterBlockchainId+* ModifyName+* ModifyParameters+* VerifyBlockchainId+* QueryBlockChainId+* LookupBlockchainId+* QueryBlockchainOwner+* QueryBlockchainName(Blockchain-id, NameType)+* QueryParentBlockchainId++## Rationale++The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.+With the success of Bitcoin and Ethereum, various blockchains such as EOS, Ripple, Litecoin, Besu, Wanchain and the like have been developed and are growing at a fast pace.  There are also other private and consortium blockchains such as Hyperledger Fabric, Hyperledger Besu, Stellar, Corda, Quorum that only allow nodes with permitted identities to join the blockchain network.  The growth of public and private blockchains imposes+challenges for inter-chain interoperability, particularly when these chains are+heterogeneous and incompatible.+Enterprise Ethereum Alliance formed Crosschain Interoperability Task Force (CITF) to look into common crosschain problems and solutions. CITF team noticed that there is a lack of unique identifier to charaterise and describe a blockchain. Several proprosals were discussed in EEA Crosschain Interoperability Task Force meetings and discussions.  We have considered various alternative specifications such as using a random unique hex string to represent a blockchain.  The drawback of this method is that the random id can not be used to verify a blockchain's intrinsic identity such as the blockhash of the genesis block.  A second alternative is simply using a genesis blockhash to represent a blockchain id for crosschain operations.  The drawback of this is that this id does not have information about the property of the blockchain and it has problem when a blockchain is forked into two blockchain.  After various discussion, we finally came up with hybrid crosschain identity specification that allows a blockchain to be identified and verified both manually and through computer programs.++## Backwards Compatibility++Crosschainid can be backward compatible with EIP-155.  The crosschain id contains a 4 byte segment to record the chainid based on EIP-155.++## Test Cases

Please provide concrete test cases for the EIP - otherwise it is recommended to remove this section.

weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>+replaces (*optional): <EIP number(s)>+---++## Simple Summary++Today chainid definition as specified in EIP-155 is an integer type.  This is not unique enough to identify all public and private blockchains.  A blockchain identifier (crosschain id) should be unique and satisfy the following requirements:++should provide identification, description, and discovery of blockchains.+should provide unique identification of each blockchain in the crosschain service ecosystem.+should provide descriptions for a blockchain identities such as chainId, name, type, consensus scheme etc.+should provide discovery mechanism for supported blockchains and also for new blockchains in the ecosystem.+should provide a mechanism for a joining blockchain to register to the ecosystem.+should provide a mechanism for a blockchain to edit properties or unregister from the crosschain ecosystem.+should provide a mechanism to get some critical information of the blockchain+should provide a mechanism to differentiate an original blockchain and a forked blockchain+should provide a mechanism to verify a chainid without external registration service++Hence we provide a specification for using a 32 byte identifier to represent any blockchain.  We call this identifier crosschain-id.++## Abstract++A short (~200 word) description of the technical issue being addressed.++Crosschain operations include transfer of assets, data, message, events, and commands from one blockchain to another. In order to improve interoperability of crosschain operations, there is a need to uniquely identify source blockchain, target blockchains, and any relay chains that help facilite blockchain information tranfer.  The identifier should follow a standard format so that all platforms and decentralize applications can use this identifier to represent a blockchain and also some information in the identifier to get some characteristis of the blockchain.  We name this blockchain identifier as crosschain-id and expect Ethereum community to use crosschain-id to represent any public or private blockchain.  The crosschain-id is a 32 byte hex string and with some bytes extracted from blockchain hash and some manually defined to characterize a blockchain.  We also propose a registration and lookup service to retrieve blockchain metadata from the crosschain-id.++## Motivation++EIP-155 was proposed by Vitalik to provide a unique identifier to a blockchain to provide simple relay attack protection.  This specification defines an integer for Chainid for a blockchain and sign the chainid into a transaction data and hence present attackers to send same transaction to different blockchains. This specification will require blockchains to define a chainid and register the chainid in a public repository.++The challenge of using an integer for chainid is that it is not broad enough to cover all blockchains and it does not prevent different blockchains using the same chainid.  Also, it does not address the issue for two forked blockchains having the same chainid.++Hence there is need for a more robust blockchain identifier that will overcome these drawbacks, especially for crosschain operations where multiple chains are involved.++## Specification++The section specifies a) The crosschain id definition b) the registration smart contract the defines metadata to be associated with a crosschain id; and c) the basic functions to parse and process a crosschain id.++### Definition of a 32 byte crosschain id++| Name          | Size(bytes) | Description |+|---------------|-------------|-------------|+| Truncated Block Hash | 16 | This is the block hash of the genesis block or the block hash of of the block immediate prior to the fork for a fork of a blockchain. The 16 bytes is the 16 least significant bytes, assuming network byte order. See table XYZA below for a list of existing blockchains. |+|Native Chain ID| 4 | This is the **Chain Id** value that should be used with the blockchain when signing transactions. For blockchains that do not have a concept of **Chain Id**, this value is zero.|+|Chain Type| 2 |  See table XYZ below the current list of chain types. |+| Governance Identifier | 2 |  For new blockchains, a governance_identifier can be specified to identify an original **owner** of a blockchain, to help settle forked / main chain disputes. For all existing blockchains and for blockchains that do not have the concept of an **owner**, this field is zero. |+| Reserved | 7 | Reserved for future use. Use 000000 for now. |+| Checksum | 1 | Used to verify the integrity of the identifier. This integrity check is targetted at detecting Crosschain Identifiers mis-typed by human users. The value is calculated as the truncated SHA256 message digest of the rest of the identifier, using the least significant byte, assuming network byte order. Note that this checksum byte only detects integrity with a probability of one in 256. This probability is adequate for the intended usage of detecting typographical errors by people manually entering the Crosschain Identifier. |++### Definition of crosschain id registration smart contract++The crosschain registration smart contract provides a registration service to crosschain id and its associated meta data.  The smart contract should support the following meta data.++|Metadata Name| Description  | Examples|+|-------------|--------------|---------|+|Crosschain Id|32 byte hex id|0xabc. See the crosschain id section for details|+|Long Name|A long naname describing the blockchain.  Maximum length is 80 characters.|This long name could be **Ethereum Mainnet**, **Bitcoin Cash**, **Wanchain Mainnet** etc|+|Short Name|An abbreviated name for the blockchain. Maximum length is four characters.|For public blockchains, this will match the standard blockchain exchange name. For example, **ETC**, **BTC**, or **WAN**.|+|Nickname|Nickname of the chain. Maximum length is 10 characters.|Names such as **Rinkeby** or **Ropsten**.|+|Chain Type|A meta data for the type of the blockchains such as public or private, permissioned or permissionless| Private:permissioned|+|Chain Category|A parameter to identify whether this is mainnet, or testnet|"mainnet", "testnet"|+|Chain IP addresses and Service Provider Id|A set of IP addresses of static nodes that can be contacted to submit a crosschain transaction, and the associated name information for the company providing the service.|125.125.125.125, 10.10.20.20|+|Name Service Type|The contract naming service available on the blockchain.|The type of service, for instance **ENS**.|+|Name Service Address|The address of the name service contract on the blockchain.| |++### Crosshchain Identifier Registration Contract++To register crosschian/blockchain id, there should be grace period for comments before it become official and verified.  The registration service should support the following functions++* RegisterBlockchainId+* ModifyName+* ModifyParameters+* VerifyBlockchainId+* QueryBlockChainId+* LookupBlockchainId+* QueryBlockchainOwner+* QueryBlockchainName(Blockchain-id, NameType)+* QueryParentBlockchainId++## Rationale++The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.+With the success of Bitcoin and Ethereum, various blockchains such as EOS, Ripple, Litecoin, Besu, Wanchain and the like have been developed and are growing at a fast pace.  There are also other private and consortium blockchains such as Hyperledger Fabric, Hyperledger Besu, Stellar, Corda, Quorum that only allow nodes with permitted identities to join the blockchain network.  The growth of public and private blockchains imposes+challenges for inter-chain interoperability, particularly when these chains are+heterogeneous and incompatible.+Enterprise Ethereum Alliance formed Crosschain Interoperability Task Force (CITF) to look into common crosschain problems and solutions. CITF team noticed that there is a lack of unique identifier to charaterise and describe a blockchain. Several proprosals were discussed in EEA Crosschain Interoperability Task Force meetings and discussions.  We have considered various alternative specifications such as using a random unique hex string to represent a blockchain.  The drawback of this method is that the random id can not be used to verify a blockchain's intrinsic identity such as the blockhash of the genesis block.  A second alternative is simply using a genesis blockhash to represent a blockchain id for crosschain operations.  The drawback of this is that this id does not have information about the property of the blockchain and it has problem when a blockchain is forked into two blockchain.  After various discussion, we finally came up with hybrid crosschain identity specification that allows a blockchain to be identified and verified both manually and through computer programs.++## Backwards Compatibility++Crosschainid can be backward compatible with EIP-155.  The crosschain id contains a 4 byte segment to record the chainid based on EIP-155.++## Test Cases++The test cases should cover the generation of crosschain id, the parsing of an crosschain id to ensure the various segments of the crosschain id meets the specification.+For the crosschain registration smart contract, the test cases should cover the testing of all functions and also need to ensure that the security of each functions are properly implemented.++## Implementation

This section is generally being deprecated, so if you don't have an implementation to provide here inline I recommend removing it altogether.

weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>+replaces (*optional): <EIP number(s)>+---++## Simple Summary++Today chainid definition as specified in EIP-155 is an integer type.  This is not unique enough to identify all public and private blockchains.  A blockchain identifier (crosschain id) should be unique and satisfy the following requirements:++should provide identification, description, and discovery of blockchains.+should provide unique identification of each blockchain in the crosschain service ecosystem.+should provide descriptions for a blockchain identities such as chainId, name, type, consensus scheme etc.+should provide discovery mechanism for supported blockchains and also for new blockchains in the ecosystem.+should provide a mechanism for a joining blockchain to register to the ecosystem.+should provide a mechanism for a blockchain to edit properties or unregister from the crosschain ecosystem.+should provide a mechanism to get some critical information of the blockchain+should provide a mechanism to differentiate an original blockchain and a forked blockchain+should provide a mechanism to verify a chainid without external registration service++Hence we provide a specification for using a 32 byte identifier to represent any blockchain.  We call this identifier crosschain-id.++## Abstract++A short (~200 word) description of the technical issue being addressed.++Crosschain operations include transfer of assets, data, message, events, and commands from one blockchain to another. In order to improve interoperability of crosschain operations, there is a need to uniquely identify source blockchain, target blockchains, and any relay chains that help facilite blockchain information tranfer.  The identifier should follow a standard format so that all platforms and decentralize applications can use this identifier to represent a blockchain and also some information in the identifier to get some characteristis of the blockchain.  We name this blockchain identifier as crosschain-id and expect Ethereum community to use crosschain-id to represent any public or private blockchain.  The crosschain-id is a 32 byte hex string and with some bytes extracted from blockchain hash and some manually defined to characterize a blockchain.  We also propose a registration and lookup service to retrieve blockchain metadata from the crosschain-id.++## Motivation++EIP-155 was proposed by Vitalik to provide a unique identifier to a blockchain to provide simple relay attack protection.  This specification defines an integer for Chainid for a blockchain and sign the chainid into a transaction data and hence present attackers to send same transaction to different blockchains. This specification will require blockchains to define a chainid and register the chainid in a public repository.++The challenge of using an integer for chainid is that it is not broad enough to cover all blockchains and it does not prevent different blockchains using the same chainid.  Also, it does not address the issue for two forked blockchains having the same chainid.++Hence there is need for a more robust blockchain identifier that will overcome these drawbacks, especially for crosschain operations where multiple chains are involved.++## Specification++The section specifies a) The crosschain id definition b) the registration smart contract the defines metadata to be associated with a crosschain id; and c) the basic functions to parse and process a crosschain id.++### Definition of a 32 byte crosschain id++| Name          | Size(bytes) | Description |+|---------------|-------------|-------------|+| Truncated Block Hash | 16 | This is the block hash of the genesis block or the block hash of of the block immediate prior to the fork for a fork of a blockchain. The 16 bytes is the 16 least significant bytes, assuming network byte order. See table XYZA below for a list of existing blockchains. |+|Native Chain ID| 4 | This is the **Chain Id** value that should be used with the blockchain when signing transactions. For blockchains that do not have a concept of **Chain Id**, this value is zero.|+|Chain Type| 2 |  See table XYZ below the current list of chain types. |+| Governance Identifier | 2 |  For new blockchains, a governance_identifier can be specified to identify an original **owner** of a blockchain, to help settle forked / main chain disputes. For all existing blockchains and for blockchains that do not have the concept of an **owner**, this field is zero. |+| Reserved | 7 | Reserved for future use. Use 000000 for now. |+| Checksum | 1 | Used to verify the integrity of the identifier. This integrity check is targetted at detecting Crosschain Identifiers mis-typed by human users. The value is calculated as the truncated SHA256 message digest of the rest of the identifier, using the least significant byte, assuming network byte order. Note that this checksum byte only detects integrity with a probability of one in 256. This probability is adequate for the intended usage of detecting typographical errors by people manually entering the Crosschain Identifier. |++### Definition of crosschain id registration smart contract++The crosschain registration smart contract provides a registration service to crosschain id and its associated meta data.  The smart contract should support the following meta data.++|Metadata Name| Description  | Examples|+|-------------|--------------|---------|+|Crosschain Id|32 byte hex id|0xabc. See the crosschain id section for details|+|Long Name|A long naname describing the blockchain.  Maximum length is 80 characters.|This long name could be **Ethereum Mainnet**, **Bitcoin Cash**, **Wanchain Mainnet** etc|+|Short Name|An abbreviated name for the blockchain. Maximum length is four characters.|For public blockchains, this will match the standard blockchain exchange name. For example, **ETC**, **BTC**, or **WAN**.|+|Nickname|Nickname of the chain. Maximum length is 10 characters.|Names such as **Rinkeby** or **Ropsten**.|+|Chain Type|A meta data for the type of the blockchains such as public or private, permissioned or permissionless| Private:permissioned|+|Chain Category|A parameter to identify whether this is mainnet, or testnet|"mainnet", "testnet"|+|Chain IP addresses and Service Provider Id|A set of IP addresses of static nodes that can be contacted to submit a crosschain transaction, and the associated name information for the company providing the service.|125.125.125.125, 10.10.20.20|+|Name Service Type|The contract naming service available on the blockchain.|The type of service, for instance **ENS**.|+|Name Service Address|The address of the name service contract on the blockchain.| |++### Crosshchain Identifier Registration Contract++To register crosschian/blockchain id, there should be grace period for comments before it become official and verified.  The registration service should support the following functions++* RegisterBlockchainId+* ModifyName+* ModifyParameters+* VerifyBlockchainId+* QueryBlockChainId+* LookupBlockchainId+* QueryBlockchainOwner+* QueryBlockchainName(Blockchain-id, NameType)+* QueryParentBlockchainId++## Rationale++The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.+With the success of Bitcoin and Ethereum, various blockchains such as EOS, Ripple, Litecoin, Besu, Wanchain and the like have been developed and are growing at a fast pace.  There are also other private and consortium blockchains such as Hyperledger Fabric, Hyperledger Besu, Stellar, Corda, Quorum that only allow nodes with permitted identities to join the blockchain network.  The growth of public and private blockchains imposes+challenges for inter-chain interoperability, particularly when these chains are+heterogeneous and incompatible.+Enterprise Ethereum Alliance formed Crosschain Interoperability Task Force (CITF) to look into common crosschain problems and solutions. CITF team noticed that there is a lack of unique identifier to charaterise and describe a blockchain. Several proprosals were discussed in EEA Crosschain Interoperability Task Force meetings and discussions.  We have considered various alternative specifications such as using a random unique hex string to represent a blockchain.  The drawback of this method is that the random id can not be used to verify a blockchain's intrinsic identity such as the blockhash of the genesis block.  A second alternative is simply using a genesis blockhash to represent a blockchain id for crosschain operations.  The drawback of this is that this id does not have information about the property of the blockchain and it has problem when a blockchain is forked into two blockchain.  After various discussion, we finally came up with hybrid crosschain identity specification that allows a blockchain to be identified and verified both manually and through computer programs.++## Backwards Compatibility++Crosschainid can be backward compatible with EIP-155.  The crosschain id contains a 4 byte segment to record the chainid based on EIP-155.++## Test Cases++The test cases should cover the generation of crosschain id, the parsing of an crosschain id to ensure the various segments of the crosschain id meets the specification.+For the crosschain registration smart contract, the test cases should cover the testing of all functions and also need to ensure that the security of each functions are properly implemented.++## Implementation++The implementation requires the following++* Generate the crosschain id based on the format defined in the specification.  +* Parse the crosschain id based on the format defined in the spefication.+* For metadata asssociated with the crosschainid, the medadata needs to be registered with a smart contract.  The smart contract should implement the functions defined in the speficification.+* Once a smart contract is deployed, the owner of the smart contract can publish the smart contract address, ABI and also crosschain id specification version.+* Once a crosschain id is registered in the smart contract with extended metadata, there should be a waiting period for the community to review the registration and raise objection if there is inconsistency.++## Security Considerations++Security are considered in the following areas:

Can probably drop this sentence as it is implied by the section title.

weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>+replaces (*optional): <EIP number(s)>+---++## Simple Summary++Today chainid definition as specified in EIP-155 is an integer type.  This is not unique enough to identify all public and private blockchains.  A blockchain identifier (crosschain id) should be unique and satisfy the following requirements:++should provide identification, description, and discovery of blockchains.+should provide unique identification of each blockchain in the crosschain service ecosystem.+should provide descriptions for a blockchain identities such as chainId, name, type, consensus scheme etc.+should provide discovery mechanism for supported blockchains and also for new blockchains in the ecosystem.+should provide a mechanism for a joining blockchain to register to the ecosystem.+should provide a mechanism for a blockchain to edit properties or unregister from the crosschain ecosystem.+should provide a mechanism to get some critical information of the blockchain+should provide a mechanism to differentiate an original blockchain and a forked blockchain+should provide a mechanism to verify a chainid without external registration service++Hence we provide a specification for using a 32 byte identifier to represent any blockchain.  We call this identifier crosschain-id.++## Abstract++A short (~200 word) description of the technical issue being addressed.++Crosschain operations include transfer of assets, data, message, events, and commands from one blockchain to another. In order to improve interoperability of crosschain operations, there is a need to uniquely identify source blockchain, target blockchains, and any relay chains that help facilite blockchain information tranfer.  The identifier should follow a standard format so that all platforms and decentralize applications can use this identifier to represent a blockchain and also some information in the identifier to get some characteristis of the blockchain.  We name this blockchain identifier as crosschain-id and expect Ethereum community to use crosschain-id to represent any public or private blockchain.  The crosschain-id is a 32 byte hex string and with some bytes extracted from blockchain hash and some manually defined to characterize a blockchain.  We also propose a registration and lookup service to retrieve blockchain metadata from the crosschain-id.++## Motivation++EIP-155 was proposed by Vitalik to provide a unique identifier to a blockchain to provide simple relay attack protection.  This specification defines an integer for Chainid for a blockchain and sign the chainid into a transaction data and hence present attackers to send same transaction to different blockchains. This specification will require blockchains to define a chainid and register the chainid in a public repository.++The challenge of using an integer for chainid is that it is not broad enough to cover all blockchains and it does not prevent different blockchains using the same chainid.  Also, it does not address the issue for two forked blockchains having the same chainid.++Hence there is need for a more robust blockchain identifier that will overcome these drawbacks, especially for crosschain operations where multiple chains are involved.++## Specification++The section specifies a) The crosschain id definition b) the registration smart contract the defines metadata to be associated with a crosschain id; and c) the basic functions to parse and process a crosschain id.++### Definition of a 32 byte crosschain id++| Name          | Size(bytes) | Description |+|---------------|-------------|-------------|+| Truncated Block Hash | 16 | This is the block hash of the genesis block or the block hash of of the block immediate prior to the fork for a fork of a blockchain. The 16 bytes is the 16 least significant bytes, assuming network byte order. See table XYZA below for a list of existing blockchains. |+|Native Chain ID| 4 | This is the **Chain Id** value that should be used with the blockchain when signing transactions. For blockchains that do not have a concept of **Chain Id**, this value is zero.|+|Chain Type| 2 |  See table XYZ below the current list of chain types. |+| Governance Identifier | 2 |  For new blockchains, a governance_identifier can be specified to identify an original **owner** of a blockchain, to help settle forked / main chain disputes. For all existing blockchains and for blockchains that do not have the concept of an **owner**, this field is zero. |+| Reserved | 7 | Reserved for future use. Use 000000 for now. |+| Checksum | 1 | Used to verify the integrity of the identifier. This integrity check is targetted at detecting Crosschain Identifiers mis-typed by human users. The value is calculated as the truncated SHA256 message digest of the rest of the identifier, using the least significant byte, assuming network byte order. Note that this checksum byte only detects integrity with a probability of one in 256. This probability is adequate for the intended usage of detecting typographical errors by people manually entering the Crosschain Identifier. |++### Definition of crosschain id registration smart contract++The crosschain registration smart contract provides a registration service to crosschain id and its associated meta data.  The smart contract should support the following meta data.++|Metadata Name| Description  | Examples|+|-------------|--------------|---------|+|Crosschain Id|32 byte hex id|0xabc. See the crosschain id section for details|+|Long Name|A long naname describing the blockchain.  Maximum length is 80 characters.|This long name could be **Ethereum Mainnet**, **Bitcoin Cash**, **Wanchain Mainnet** etc|+|Short Name|An abbreviated name for the blockchain. Maximum length is four characters.|For public blockchains, this will match the standard blockchain exchange name. For example, **ETC**, **BTC**, or **WAN**.|+|Nickname|Nickname of the chain. Maximum length is 10 characters.|Names such as **Rinkeby** or **Ropsten**.|+|Chain Type|A meta data for the type of the blockchains such as public or private, permissioned or permissionless| Private:permissioned|+|Chain Category|A parameter to identify whether this is mainnet, or testnet|"mainnet", "testnet"|+|Chain IP addresses and Service Provider Id|A set of IP addresses of static nodes that can be contacted to submit a crosschain transaction, and the associated name information for the company providing the service.|125.125.125.125, 10.10.20.20|+|Name Service Type|The contract naming service available on the blockchain.|The type of service, for instance **ENS**.|+|Name Service Address|The address of the name service contract on the blockchain.| |++### Crosshchain Identifier Registration Contract++To register crosschian/blockchain id, there should be grace period for comments before it become official and verified.  The registration service should support the following functions++* RegisterBlockchainId+* ModifyName+* ModifyParameters+* VerifyBlockchainId+* QueryBlockChainId+* LookupBlockchainId+* QueryBlockchainOwner+* QueryBlockchainName(Blockchain-id, NameType)+* QueryParentBlockchainId++## Rationale++The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.+With the success of Bitcoin and Ethereum, various blockchains such as EOS, Ripple, Litecoin, Besu, Wanchain and the like have been developed and are growing at a fast pace.  There are also other private and consortium blockchains such as Hyperledger Fabric, Hyperledger Besu, Stellar, Corda, Quorum that only allow nodes with permitted identities to join the blockchain network.  The growth of public and private blockchains imposes+challenges for inter-chain interoperability, particularly when these chains are+heterogeneous and incompatible.+Enterprise Ethereum Alliance formed Crosschain Interoperability Task Force (CITF) to look into common crosschain problems and solutions. CITF team noticed that there is a lack of unique identifier to charaterise and describe a blockchain. Several proprosals were discussed in EEA Crosschain Interoperability Task Force meetings and discussions.  We have considered various alternative specifications such as using a random unique hex string to represent a blockchain.  The drawback of this method is that the random id can not be used to verify a blockchain's intrinsic identity such as the blockhash of the genesis block.  A second alternative is simply using a genesis blockhash to represent a blockchain id for crosschain operations.  The drawback of this is that this id does not have information about the property of the blockchain and it has problem when a blockchain is forked into two blockchain.  After various discussion, we finally came up with hybrid crosschain identity specification that allows a blockchain to be identified and verified both manually and through computer programs.++## Backwards Compatibility++Crosschainid can be backward compatible with EIP-155.  The crosschain id contains a 4 byte segment to record the chainid based on EIP-155.

I don't think this is true. Ethereum clients today validate transactions by extracting the chain id from v. Even if there is a 4 byte segment to record the chainid, clients would need to know how to extract it. This would be a core change and necessitate a hard fork.

weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:

Please update with URL to discuss this EIP. https://ethereum-magicians.org is preferred.

weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>+replaces (*optional): <EIP number(s)>+---++## Simple Summary++Today chainid definition as specified in EIP-155 is an integer type.  This is not unique enough to identify all public and private blockchains.  A blockchain identifier (crosschain id) should be unique and satisfy the following requirements:++should provide identification, description, and discovery of blockchains.+should provide unique identification of each blockchain in the crosschain service ecosystem.+should provide descriptions for a blockchain identities such as chainId, name, type, consensus scheme etc.+should provide discovery mechanism for supported blockchains and also for new blockchains in the ecosystem.+should provide a mechanism for a joining blockchain to register to the ecosystem.+should provide a mechanism for a blockchain to edit properties or unregister from the crosschain ecosystem.+should provide a mechanism to get some critical information of the blockchain+should provide a mechanism to differentiate an original blockchain and a forked blockchain+should provide a mechanism to verify a chainid without external registration service++Hence we provide a specification for using a 32 byte identifier to represent any blockchain.  We call this identifier crosschain-id.++## Abstract++A short (~200 word) description of the technical issue being addressed.++Crosschain operations include transfer of assets, data, message, events, and commands from one blockchain to another. In order to improve interoperability of crosschain operations, there is a need to uniquely identify source blockchain, target blockchains, and any relay chains that help facilite blockchain information tranfer.  The identifier should follow a standard format so that all platforms and decentralize applications can use this identifier to represent a blockchain and also some information in the identifier to get some characteristis of the blockchain.  We name this blockchain identifier as crosschain-id and expect Ethereum community to use crosschain-id to represent any public or private blockchain.  The crosschain-id is a 32 byte hex string and with some bytes extracted from blockchain hash and some manually defined to characterize a blockchain.  We also propose a registration and lookup service to retrieve blockchain metadata from the crosschain-id.++## Motivation++EIP-155 was proposed by Vitalik to provide a unique identifier to a blockchain to provide simple relay attack protection.  This specification defines an integer for Chainid for a blockchain and sign the chainid into a transaction data and hence present attackers to send same transaction to different blockchains. This specification will require blockchains to define a chainid and register the chainid in a public repository.++The challenge of using an integer for chainid is that it is not broad enough to cover all blockchains and it does not prevent different blockchains using the same chainid.  Also, it does not address the issue for two forked blockchains having the same chainid.++Hence there is need for a more robust blockchain identifier that will overcome these drawbacks, especially for crosschain operations where multiple chains are involved.++## Specification++The section specifies a) The crosschain id definition b) the registration smart contract the defines metadata to be associated with a crosschain id; and c) the basic functions to parse and process a crosschain id.++### Definition of a 32 byte crosschain id++| Name          | Size(bytes) | Description |+|---------------|-------------|-------------|+| Truncated Block Hash | 16 | This is the block hash of the genesis block or the block hash of of the block immediate prior to the fork for a fork of a blockchain. The 16 bytes is the 16 least significant bytes, assuming network byte order. See table XYZA below for a list of existing blockchains. |+|Native Chain ID| 4 | This is the **Chain Id** value that should be used with the blockchain when signing transactions. For blockchains that do not have a concept of **Chain Id**, this value is zero.|+|Chain Type| 2 |  See table XYZ below the current list of chain types. |+| Governance Identifier | 2 |  For new blockchains, a governance_identifier can be specified to identify an original **owner** of a blockchain, to help settle forked / main chain disputes. For all existing blockchains and for blockchains that do not have the concept of an **owner**, this field is zero. |+| Reserved | 7 | Reserved for future use. Use 000000 for now. |+| Checksum | 1 | Used to verify the integrity of the identifier. This integrity check is targetted at detecting Crosschain Identifiers mis-typed by human users. The value is calculated as the truncated SHA256 message digest of the rest of the identifier, using the least significant byte, assuming network byte order. Note that this checksum byte only detects integrity with a probability of one in 256. This probability is adequate for the intended usage of detecting typographical errors by people manually entering the Crosschain Identifier. |++### Definition of crosschain id registration smart contract++The crosschain registration smart contract provides a registration service to crosschain id and its associated meta data.  The smart contract should support the following meta data.++|Metadata Name| Description  | Examples|+|-------------|--------------|---------|+|Crosschain Id|32 byte hex id|0xabc. See the crosschain id section for details|+|Long Name|A long naname describing the blockchain.  Maximum length is 80 characters.|This long name could be **Ethereum Mainnet**, **Bitcoin Cash**, **Wanchain Mainnet** etc|+|Short Name|An abbreviated name for the blockchain. Maximum length is four characters.|For public blockchains, this will match the standard blockchain exchange name. For example, **ETC**, **BTC**, or **WAN**.|+|Nickname|Nickname of the chain. Maximum length is 10 characters.|Names such as **Rinkeby** or **Ropsten**.|+|Chain Type|A meta data for the type of the blockchains such as public or private, permissioned or permissionless| Private:permissioned|+|Chain Category|A parameter to identify whether this is mainnet, or testnet|"mainnet", "testnet"|+|Chain IP addresses and Service Provider Id|A set of IP addresses of static nodes that can be contacted to submit a crosschain transaction, and the associated name information for the company providing the service.|125.125.125.125, 10.10.20.20|+|Name Service Type|The contract naming service available on the blockchain.|The type of service, for instance **ENS**.|+|Name Service Address|The address of the name service contract on the blockchain.| |++### Crosshchain Identifier Registration Contract++To register crosschian/blockchain id, there should be grace period for comments before it become official and verified.  The registration service should support the following functions++* RegisterBlockchainId+* ModifyName+* ModifyParameters+* VerifyBlockchainId+* QueryBlockChainId+* LookupBlockchainId+* QueryBlockchainOwner+* QueryBlockchainName(Blockchain-id, NameType)+* QueryParentBlockchainId++## Rationale++The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.
weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>+replaces (*optional): <EIP number(s)>+---++## Simple Summary++Today chainid definition as specified in EIP-155 is an integer type.  This is not unique enough to identify all public and private blockchains.  A blockchain identifier (crosschain id) should be unique and satisfy the following requirements:

Is this truly case? I believe v can be up to 2^256. Since the chain id is multiplied by 2, that should leave 2^255 identifiers?

weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>+replaces (*optional): <EIP number(s)>+---++## Simple Summary

The simple summary should really only be a couple sentences. The requirements specified here would make more sense in the motivation / rationale.

weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>+replaces (*optional): <EIP number(s)>+---++## Simple Summary++Today chainid definition as specified in EIP-155 is an integer type.  This is not unique enough to identify all public and private blockchains.  A blockchain identifier (crosschain id) should be unique and satisfy the following requirements:++should provide identification, description, and discovery of blockchains.+should provide unique identification of each blockchain in the crosschain service ecosystem.+should provide descriptions for a blockchain identities such as chainId, name, type, consensus scheme etc.+should provide discovery mechanism for supported blockchains and also for new blockchains in the ecosystem.+should provide a mechanism for a joining blockchain to register to the ecosystem.+should provide a mechanism for a blockchain to edit properties or unregister from the crosschain ecosystem.+should provide a mechanism to get some critical information of the blockchain+should provide a mechanism to differentiate an original blockchain and a forked blockchain+should provide a mechanism to verify a chainid without external registration service++Hence we provide a specification for using a 32 byte identifier to represent any blockchain.  We call this identifier crosschain-id.++## Abstract++A short (~200 word) description of the technical issue being addressed.++Crosschain operations include transfer of assets, data, message, events, and commands from one blockchain to another. In order to improve interoperability of crosschain operations, there is a need to uniquely identify source blockchain, target blockchains, and any relay chains that help facilite blockchain information tranfer.  The identifier should follow a standard format so that all platforms and decentralize applications can use this identifier to represent a blockchain and also some information in the identifier to get some characteristis of the blockchain.  We name this blockchain identifier as crosschain-id and expect Ethereum community to use crosschain-id to represent any public or private blockchain.  The crosschain-id is a 32 byte hex string and with some bytes extracted from blockchain hash and some manually defined to characterize a blockchain.  We also propose a registration and lookup service to retrieve blockchain metadata from the crosschain-id.++## Motivation++EIP-155 was proposed by Vitalik to provide a unique identifier to a blockchain to provide simple relay attack protection.  This specification defines an integer for Chainid for a blockchain and sign the chainid into a transaction data and hence present attackers to send same transaction to different blockchains. This specification will require blockchains to define a chainid and register the chainid in a public repository.++The challenge of using an integer for chainid is that it is not broad enough to cover all blockchains and it does not prevent different blockchains using the same chainid.  Also, it does not address the issue for two forked blockchains having the same chainid.++Hence there is need for a more robust blockchain identifier that will overcome these drawbacks, especially for crosschain operations where multiple chains are involved.++## Specification++The section specifies a) The crosschain id definition b) the registration smart contract the defines metadata to be associated with a crosschain id; and c) the basic functions to parse and process a crosschain id.++### Definition of a 32 byte crosschain id++| Name          | Size(bytes) | Description |+|---------------|-------------|-------------|+| Truncated Block Hash | 16 | This is the block hash of the genesis block or the block hash of of the block immediate prior to the fork for a fork of a blockchain. The 16 bytes is the 16 least significant bytes, assuming network byte order. See table XYZA below for a list of existing blockchains. |+|Native Chain ID| 4 | This is the **Chain Id** value that should be used with the blockchain when signing transactions. For blockchains that do not have a concept of **Chain Id**, this value is zero.|+|Chain Type| 2 |  See table XYZ below the current list of chain types. |+| Governance Identifier | 2 |  For new blockchains, a governance_identifier can be specified to identify an original **owner** of a blockchain, to help settle forked / main chain disputes. For all existing blockchains and for blockchains that do not have the concept of an **owner**, this field is zero. |+| Reserved | 7 | Reserved for future use. Use 000000 for now. |+| Checksum | 1 | Used to verify the integrity of the identifier. This integrity check is targetted at detecting Crosschain Identifiers mis-typed by human users. The value is calculated as the truncated SHA256 message digest of the rest of the identifier, using the least significant byte, assuming network byte order. Note that this checksum byte only detects integrity with a probability of one in 256. This probability is adequate for the intended usage of detecting typographical errors by people manually entering the Crosschain Identifier. |++### Definition of crosschain id registration smart contract++The crosschain registration smart contract provides a registration service to crosschain id and its associated meta data.  The smart contract should support the following meta data.++|Metadata Name| Description  | Examples|+|-------------|--------------|---------|+|Crosschain Id|32 byte hex id|0xabc. See the crosschain id section for details|+|Long Name|A long naname describing the blockchain.  Maximum length is 80 characters.|This long name could be **Ethereum Mainnet**, **Bitcoin Cash**, **Wanchain Mainnet** etc|+|Short Name|An abbreviated name for the blockchain. Maximum length is four characters.|For public blockchains, this will match the standard blockchain exchange name. For example, **ETC**, **BTC**, or **WAN**.|+|Nickname|Nickname of the chain. Maximum length is 10 characters.|Names such as **Rinkeby** or **Ropsten**.|+|Chain Type|A meta data for the type of the blockchains such as public or private, permissioned or permissionless| Private:permissioned|+|Chain Category|A parameter to identify whether this is mainnet, or testnet|"mainnet", "testnet"|+|Chain IP addresses and Service Provider Id|A set of IP addresses of static nodes that can be contacted to submit a crosschain transaction, and the associated name information for the company providing the service.|125.125.125.125, 10.10.20.20|+|Name Service Type|The contract naming service available on the blockchain.|The type of service, for instance **ENS**.|+|Name Service Address|The address of the name service contract on the blockchain.| |++### Crosshchain Identifier Registration Contract++To register crosschian/blockchain id, there should be grace period for comments before it become official and verified.  The registration service should support the following functions++* RegisterBlockchainId+* ModifyName+* ModifyParameters+* VerifyBlockchainId+* QueryBlockChainId+* LookupBlockchainId+* QueryBlockchainOwner+* QueryBlockchainName(Blockchain-id, NameType)+* QueryParentBlockchainId++## Rationale

This section is generally reserved to discuss why specific decisions were made regarding the specification. The motivation section is a better place for longer prose explanations of why the EIP is being specified.

weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>+replaces (*optional): <EIP number(s)>+---++## Simple Summary++Today chainid definition as specified in EIP-155 is an integer type.  This is not unique enough to identify all public and private blockchains.  A blockchain identifier (crosschain id) should be unique and satisfy the following requirements:++should provide identification, description, and discovery of blockchains.+should provide unique identification of each blockchain in the crosschain service ecosystem.+should provide descriptions for a blockchain identities such as chainId, name, type, consensus scheme etc.+should provide discovery mechanism for supported blockchains and also for new blockchains in the ecosystem.+should provide a mechanism for a joining blockchain to register to the ecosystem.+should provide a mechanism for a blockchain to edit properties or unregister from the crosschain ecosystem.+should provide a mechanism to get some critical information of the blockchain+should provide a mechanism to differentiate an original blockchain and a forked blockchain+should provide a mechanism to verify a chainid without external registration service++Hence we provide a specification for using a 32 byte identifier to represent any blockchain.  We call this identifier crosschain-id.++## Abstract++A short (~200 word) description of the technical issue being addressed.++Crosschain operations include transfer of assets, data, message, events, and commands from one blockchain to another. In order to improve interoperability of crosschain operations, there is a need to uniquely identify source blockchain, target blockchains, and any relay chains that help facilite blockchain information tranfer.  The identifier should follow a standard format so that all platforms and decentralize applications can use this identifier to represent a blockchain and also some information in the identifier to get some characteristis of the blockchain.  We name this blockchain identifier as crosschain-id and expect Ethereum community to use crosschain-id to represent any public or private blockchain.  The crosschain-id is a 32 byte hex string and with some bytes extracted from blockchain hash and some manually defined to characterize a blockchain.  We also propose a registration and lookup service to retrieve blockchain metadata from the crosschain-id.++## Motivation++EIP-155 was proposed by Vitalik to provide a unique identifier to a blockchain to provide simple relay attack protection.  This specification defines an integer for Chainid for a blockchain and sign the chainid into a transaction data and hence present attackers to send same transaction to different blockchains. This specification will require blockchains to define a chainid and register the chainid in a public repository.++The challenge of using an integer for chainid is that it is not broad enough to cover all blockchains and it does not prevent different blockchains using the same chainid.  Also, it does not address the issue for two forked blockchains having the same chainid.++Hence there is need for a more robust blockchain identifier that will overcome these drawbacks, especially for crosschain operations where multiple chains are involved.++## Specification++The section specifies a) The crosschain id definition b) the registration smart contract the defines metadata to be associated with a crosschain id; and c) the basic functions to parse and process a crosschain id.++### Definition of a 32 byte crosschain id++| Name          | Size(bytes) | Description |+|---------------|-------------|-------------|+| Truncated Block Hash | 16 | This is the block hash of the genesis block or the block hash of of the block immediate prior to the fork for a fork of a blockchain. The 16 bytes is the 16 least significant bytes, assuming network byte order. See table XYZA below for a list of existing blockchains. |+|Native Chain ID| 4 | This is the **Chain Id** value that should be used with the blockchain when signing transactions. For blockchains that do not have a concept of **Chain Id**, this value is zero.|+|Chain Type| 2 |  See table XYZ below the current list of chain types. |+| Governance Identifier | 2 |  For new blockchains, a governance_identifier can be specified to identify an original **owner** of a blockchain, to help settle forked / main chain disputes. For all existing blockchains and for blockchains that do not have the concept of an **owner**, this field is zero. |+| Reserved | 7 | Reserved for future use. Use 000000 for now. |+| Checksum | 1 | Used to verify the integrity of the identifier. This integrity check is targetted at detecting Crosschain Identifiers mis-typed by human users. The value is calculated as the truncated SHA256 message digest of the rest of the identifier, using the least significant byte, assuming network byte order. Note that this checksum byte only detects integrity with a probability of one in 256. This probability is adequate for the intended usage of detecting typographical errors by people manually entering the Crosschain Identifier. |++### Definition of crosschain id registration smart contract++The crosschain registration smart contract provides a registration service to crosschain id and its associated meta data.  The smart contract should support the following meta data.++|Metadata Name| Description  | Examples|+|-------------|--------------|---------|+|Crosschain Id|32 byte hex id|0xabc. See the crosschain id section for details|+|Long Name|A long naname describing the blockchain.  Maximum length is 80 characters.|This long name could be **Ethereum Mainnet**, **Bitcoin Cash**, **Wanchain Mainnet** etc|+|Short Name|An abbreviated name for the blockchain. Maximum length is four characters.|For public blockchains, this will match the standard blockchain exchange name. For example, **ETC**, **BTC**, or **WAN**.|+|Nickname|Nickname of the chain. Maximum length is 10 characters.|Names such as **Rinkeby** or **Ropsten**.|+|Chain Type|A meta data for the type of the blockchains such as public or private, permissioned or permissionless| Private:permissioned|+|Chain Category|A parameter to identify whether this is mainnet, or testnet|"mainnet", "testnet"|+|Chain IP addresses and Service Provider Id|A set of IP addresses of static nodes that can be contacted to submit a crosschain transaction, and the associated name information for the company providing the service.|125.125.125.125, 10.10.20.20|+|Name Service Type|The contract naming service available on the blockchain.|The type of service, for instance **ENS**.|+|Name Service Address|The address of the name service contract on the blockchain.| |++### Crosshchain Identifier Registration Contract++To register crosschian/blockchain id, there should be grace period for comments before it become official and verified.  The registration service should support the following functions++* RegisterBlockchainId+* ModifyName+* ModifyParameters+* VerifyBlockchainId+* QueryBlockChainId+* LookupBlockchainId+* QueryBlockchainOwner+* QueryBlockchainName(Blockchain-id, NameType)+* QueryParentBlockchainId++## Rationale++The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.+With the success of Bitcoin and Ethereum, various blockchains such as EOS, Ripple, Litecoin, Besu, Wanchain and the like have been developed and are growing at a fast pace.  There are also other private and consortium blockchains such as Hyperledger Fabric, Hyperledger Besu, Stellar, Corda, Quorum that only allow nodes with permitted identities to join the blockchain network.  The growth of public and private blockchains imposes+challenges for inter-chain interoperability, particularly when these chains are

Looks like a few awkward new lines here.

weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>
weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>+replaces (*optional): <EIP number(s)>
weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>
eip: 3220
weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>

Generally, we prefer Github handles now. It allows you be tagged by the automerge bot when changes are pending on your EIP.

weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC

If you're proposing a standard for signing messages that is not compatible with EIP-155, the category should be Core.

weijia31415

comment created time in 8 hours

Pull request review commentethereum/EIPs

EIP-crosschain-id proposal

+---+eip: <to be assigned>+title: Crosschain Identifier Specification+author: Weijia Zhang <weijia@wanchain.org>, Peter Robinson <peter.robinson@consensys.net>+discussions-to:+status: Draft+type: Standards Track+category: ERC+created: 2020-10-21+requires (*optional): <EIP number(s)>+replaces (*optional): <EIP number(s)>+---++## Simple Summary++Today chainid definition as specified in EIP-155 is an integer type.  This is not unique enough to identify all public and private blockchains.  A blockchain identifier (crosschain id) should be unique and satisfy the following requirements:++should provide identification, description, and discovery of blockchains.+should provide unique identification of each blockchain in the crosschain service ecosystem.+should provide descriptions for a blockchain identities such as chainId, name, type, consensus scheme etc.+should provide discovery mechanism for supported blockchains and also for new blockchains in the ecosystem.+should provide a mechanism for a joining blockchain to register to the ecosystem.+should provide a mechanism for a blockchain to edit properties or unregister from the crosschain ecosystem.+should provide a mechanism to get some critical information of the blockchain+should provide a mechanism to differentiate an original blockchain and a forked blockchain+should provide a mechanism to verify a chainid without external registration service++Hence we provide a specification for using a 32 byte identifier to represent any blockchain.  We call this identifier crosschain-id.++## Abstract++A short (~200 word) description of the technical issue being addressed.
weijia31415

comment created time in 8 hours

pull request commentethereum/EIPs

Update and rename CNAME to CNAME MIST BROWSER

Hurtadodayna37@gmail.com

0xC11C3cfd8C997E684A76336730A86790a661358B

hurtadodayna

comment created time in 9 hours

PR opened ethereum/EIPs

Update and rename CNAME to CNAME MIST BROWSER

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
+3 -1

0 comment

2 changed files

pr created time in 9 hours

PR opened ethereum/EIPs

EIP-crosschain-id proposal

This document was created by EEA (Enterprise Ethereum Alliance) Crosschain Interoperablitty Task Force and is submitted as a EIP proposal. The document was shared with Hudson Jameson for EIP editor's feedback.

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

  • The PR edits only existing draft PRs.
  • The build passes.
  • Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside <triangular brackets>.
  • If matching on email address, the email address is the one publicly listed on your GitHub profile.
+131 -0

0 comment

1 changed file

pr created time in 9 hours

issue openedWICG/file-system-access

How to prevent FileSystem Access

Hello, I am trying to design a tool to avoid malicious use of this API. So, how can I create a tool to stop the events of these API even though the user gives a permission to website. For example, how can I hook into writable.close() function? So that before the website's permanent activity I can somehow analyze the website to decide whether it is being malicious.

Thank you.

created time in 9 hours

push eventkevinsimper/localsearch

Abdallah

commit sha 1658cb555f7fed64b6525094a36842a7e49bad29

Fix typos

view details

Abdallah

commit sha 5b1f706a14ce8ad0cb2b6224e29c47c1e58e1e35

Merge pull request #2 from aabedraba/fix-typos Fix typos

view details

push time in 13 hours

PR merged kevinsimper/localsearch

Fix typos
+2 -2

0 comment

1 changed file

aabedraba

pr closed time in 13 hours

push eventkevinsimper/localsearch

Abdallah Abedraba

commit sha bfbee755abcfb9f406c37bb8327ded8e68814e9c

Add omnibox suggestions

view details

Abdallah

commit sha 732a44947025ce1c0e4e6c3cb533e9be53daf108

Merge pull request #3 from aabedraba/master Add omnibox suggestions

view details

push time in 13 hours

more