Se arreglaron los DCIPs

This commit is contained in:
Team1 2023-04-12 20:28:52 +00:00
parent 743d90e423
commit f07399d149
19 changed files with 367 additions and 1898 deletions

2
CNAME
View File

@ -1 +1 @@
eips.ethereum.org dcips.decentralizedclimate.org

11
EIPS/dcip-1.md Normal file
View File

@ -0,0 +1,11 @@
---
eip: 1
title: General Assembly No. 2 (Unfinished)
author: Decentralized Climate (@DecentralizedClimate)
status: Living
type: Standards Track
category: Core
created: 2023-01-02
---

131
EIPS/dcip-2.md Normal file
View File

@ -0,0 +1,131 @@
---
eip: 2
title: Monthly activity report of the Decentralized Climate Foundation A.C. January.
author: Decentralized Climate <@decentralizedclimate>
status: Final
type: Standards Track
category: Core
created: 2023-02-05
---
![](https://i.imgur.com/Hc9JjRZ.png)
**5 February 2023**
:::info
#### Table of Contents
[TOC]
:::
## :beginner: Introduction.
This monthly report aims to provide an overview of the activities, projects, and finances of the Decentralized Climate Foundation Civil Association. Through this document, we seek to inform our members and collaborators of the achievements and challenges we face during the month. Furthermore, we hope to provide transparency and accountability on the use of resources and progress towards our long-term goals. This report includes details on the activities carried out, the status of ongoing projects, a financial analysis, and future planning.
## 📈 Activities carried out.
The activities for the month of January were divided into 7 main divisions which are subdivided into specific tasks each of which are as follows:
### **Maxcoin MVP.**
**From 1 to 2 January.** In this activity, the main and only revision of the MVP that the Foundation prepared for Maxcurrent was carried out, technical and orthographic revisions were made and final details were fine-tuned to present it to Maxcurrent's staff. A total of 2 people participated.
**4th January.** In this activity, the MVP of Maxcoin was recorded on the Github & Gitlab platforms to provide evidence of the work done and so that the entire community of developers from these platforms could be familiar with the project and provide feedback. The main developer of the project participated.
**6th January.** This activity proposed the discussion, review and voting of Maxcurrent's MVP project to be approved by the members of the Decentralized Climate Foundation's Board of Directors in the Foundation's official DAO. All members of the Board of Directors participated in this activity.
The vote can be consulted at the Annexe 1.
### **Deploy and vote Phase 0 DAO.**
**6th January.** In this activity, the phase 0 for the use of the DAO Company template in Aragon was proposed for discussion, review, and voting, containing the proposal for a new workflow model proposed for the Foundation, with the aim of being approved by the members of the Decentralized Climate Foundation's Board of Directors in the official DAO of the Foundation. All members of the Board of Directors participated in this activity.
The voting can be consulted at the Annexe 2.
The proposal can be found at the Annexe 3.
### **R&D Phase 1 DAO.**
**8th January.** Tests were conducted on different DAOs from the Aragon platform but on a different test network, in this case the chosen network was POLYGON. Tests had not been conducted on this network before and it was determined to conduct them so as not to focus on a single test network that until this point was Goërli, this in order to determine the best options for implementation within the decision-making processes within the organization. It was a research, testing, and documentation effort. The main developers of the foundation participated in this activity.
**8th January.** Likewise, within the aforementioned activity, a check was carried out on the previous research carried out on how to use DECA in Phase 1 to implement it in the internal processes of the Foundation's governance. In this same activity, the two main developers of the Foundation's projects participated again.
### **Administration.**
**January 2nd.** The pending tasks for the year 2022 regarding the administration of the Foundation have been completed, such as the review of some outstanding accounts, the start of the annual report, and matters regarding university students who will be presenting their social service. The Director of the Foundation participated in these tasks.
**6th January.** In order to decentralise functions within the Foundation, the General Director starts to cede limited control of his functions and delegates certain responsibilities to a new associate. Within these delegated functions are the ones to have access to the Foundation's accounts, as well as cryptocurrency wallets, bank accounts, and online access. The general Director and the new member of the foundation participated in these tasks.
**13th January.** The General Director of the Foundation informs the Board of Directors of his intentions to step down from the position due to personal matters that prevent him from performing his duties properly.
**20th January.** The General Director of the Decentralized Climate Foundation Civil Association presents his resignation letter citing personal reasons, causing all ongoing activities to be halted in order to assess the current situation and ask the General Director for the reason behind his decision. All members of the Foundation participated.
The resignation letter can be found in the Annexe 4.
**21st January.** From this date onwards, the activities that the members of the Foundation were carrying out in order to devise a restructuring strategy to cover the vacancy of the General Directorate and the tasks that the Director was performing were halted. All members of the Board of Directors participated in this planning activity.
**22nd January.** Different administrative tasks that the former Director was performing were carried out, such as the reorganization of documents and the creation of a new one proposing the rights and obligations of the members of the Board of Directors. All members of the Board participated in these tasks.
The document outlining the responsibilities of the members of the Board of Directors can be found in Annexe 5.
### **Mantenance.**
In this section, maintenance activities are carried out on the main infrastructure of the Foundation such as servers, computer equipment and other electronic devices that the foundation uses for its daily operation.
The two main developers of the Foundation actively participate in these activities.
### **Social Services Requirements.**
## :moneybag: Finance.
The Finance section is located in Annexe 6, which details the income, expenses, and expenditures made by the foundation throughout the month.
![](https://i.imgur.com/VrkHVGe.png)
## :clipboard:Ongoing projects.
In this section, we show the works we are currently involved in.
We are currently working with the first Social Service, who is helping us with the documentation of the Foundation's internal processes.
We are teaching them agile methodologies as a way of working and organizing, and we are providing them with leveling workshops so that they can later join the intense work required to streamline the projects and tasks that the Foundation will develop.
The Foundation is also in search of funds and will probably enroll in an entrepreneurship project bootcamp in the city of Guadalajara, in the state of Jalisco, Mexico.
## :pencil:Future goals and objectives
The future projects and new objectives that the Foundation plans to carry out are broadly as follows:
The DECA 2 project, the updating of its diagrams and documentation by NSI in order to apply for an economic stimulus from CONACyT. Within this project, the removal of carbon credits from the processes of this cryptocurrency is proposed, as well as the updating of references and documentation, the updating of MVP information by adding use cases and MAXCOIN sequences, the updating of the working model between NSI and the Foundation, and the creation of a DCF and NSI agreement.
There is another high-interest project to be developed within the Foundation, which is the MVP of the IHS company. As it is a project proposal, the plan is to start with the research of the necessary information to develop the MVP and a development proposal. This project is initially only in the research phase.
The Foundation is also working on important matters, such as the funding options that exist. There are two viable options to obtain resources, both of which are government agencies, although the procedures are completely different.
The first is called CLUNI, which is a stimulus granted by the Mexican State to Civil Associations and somewhat guarantees the obtaining of resources from the Mexican government.
The second is the CONACyT scholarship, which is the National Council of Science and Technology of the Mexican Government, and is a stimulus with which the Foundation, through the DECA 2 project, plans to attract funds for technology development.
These are some of the projects that the Foundation has for the future to work on in the coming months, hoping they will be completed as soon as possible.
## 🎯 Conclusions and recommendations
In conclusion, during the month of january, we have made significant progress in achieving the objectives of our foundation. We have carried out fundraising activities and identified opportunities to improve our internal management. In addition, we have updated and organized our donor database.
Regarding recommendations, we consider it important to continue working on fundraising to finance the ongoing projects. Also, it is essential to implement measures to improve efficiency in the management of the foundation's resources, with the aim of maximizing its impact. Finally, we recommend continuing to update and organize the donor database, which will allow us to establish more effective and long-lasting relationships with our collaborators.
In summary, we believe that this has been a very productive month for our foundation, and we are confident that by following these recommendations we will be able to achieve our short and long-term goals.
## :beginner:Annexes
1. https://client.aragon.org/#/dcf/0xfcdf01f009187e604380ae3e964998befd733c7e/vote/19/
2. https://client.aragon.org/#/dcf/0xfcdf01f009187e604380ae3e964998befd733c7e/vote/20/
3. https://hackmd.io/A9LNZFTlQsC32gqDw1C7EQ
4. https://hackmd.io/@DEKIS/SkNcuOOjs
5. https://hackmd.io/gMphw3QiRvSI2WK3Ml2GkA?both
6. https://nextcloud.neetsec.com/index.php/s/ZPE5ZQ2356ZJkxL
7. https://hackmd.io/oycdQimKSnKtehXKRkz3kA

9
EIPS/dcip-3.md Normal file
View File

@ -0,0 +1,9 @@
---
eip: 3
title: General Assembly No. 3 (Unfinished)
author: Decentralized Climate <@decentralizedclimate>
status: Living
type: Standards Track
category: Core
created: 2023-04-12
---

87
EIPS/do_di/AAGO.md Normal file
View File

@ -0,0 +1,87 @@
cta de Asamblea General Ordinaria N°1
## Decentralized Climate Foundation A.C.
En la Ciudad de México, Delegación Benito Juárez, a los 31 días del mes de Diciembre del año 2022, en el domicilio de la calle San Antonio Nº 123, Departamento 03, en las oficinas de la Decentralized Climate Foundation A.C., siendo las 17:00 horas, y habiéndose reunido el Quórum necesario conforme las directrices del Acta Constitutiva, se da comienzo a la Asamblea General Ordinaria, convocada por la Comisión Directiva, a fin de tratar el siguiente Orden del Día:
1) Lectura del Acta Constitutiva e Informe de Actividades Realizadas
2) Tratamiento y aprobación del Balance Anual correspondiente al primer año de actividades
3) Elección de los cargos Presidente y Secretario
4) Elección de los cargos de Tesorero
___
Esta Asamblea es presidida por el C. Luis Alberto Saavedra Nieto, Director y asistido por el Ing. David Pérez-Negron Rocha, fundador.
Se informa que se encuentra reunido el Quórum necesario para dar comienzo a la Asamblea con la presencia de la totalidad de sus asociados, según Planilla de Asistencia.
Acto seguido se pasa a tratar el **PRIMER PUNTO** del orden del día.
Luego de la lectura del Informe de Actividades Realizadas y después de un breve intercambio de opiniones se aprueba que los asociados designados para suscribir la presente Acta sean Luis Alberto Saavedra Nieto y David Perez-Negron Rocha.
A continuación se trata el **SEGUNDO PUNTO** del Orden del Día.
Luego de la escucha del Reporte un breve diálogo al respecto, la votación dio como resultado la **APROBACIÓN POR UNANIMIDAD** el Balance Anual tratado; quedando de esta manera aprobado por mayoría el Balance Anual.
Se pasa a tratar el **TERCER PUNTO** del Orden del Día.
Habiendo presentación de las Listas, se procede a su lectura. Luego de un breve debate e intercambio de opiniones entre los asociados, la votación dio como resultado la APROBACIÓN POR UNANIMIDAD de la Lista, se proponen como candidatos a las siguientes personas:
**Para el cargo de Secretario: el C. Alfonso Núñez Navarro
Para el cargo de Tesorero: el C. Omar Octavio Huerta Valdez**
Los asociados propuestos como candidatos aceptan su candidatura.
Luego de un breve debate e intercambio de opiniones la votación dio como resultado:
Para el cargo de Secretario, **4 votos para Alfonso Núñez Navarro, 1 abstención, 0 votos en contra.**
Se pasa a tratar el **PUNTO CUATRO** del Orden del Día.
Habiendo presentación de Listas, se procede a su lectura. Luego de un breve debate e intercambio de opiniones la votación dio como resultado la APROBACIÓN POR UNANIMIDAD de la Lista. Luego de un breve debate e intercambio de opiniones la votación dio como resultado:
Para el cargo de Tesorero, **4 votos para Omar Octavio Huerta Valdez, 1 abstención, 0 votos en contra.**
Finalmente se trata el **PUNTO QUINTO** del Orden del Día.
Los asociados propuestos como candidatos aceptan el cargo para el que fueron electos.
De esta forma se proclaman a las autoridades electas por el término de 5 años y contar desde el día de la fecha, con la siguiente conformación:
**Del Consejo General**
Secretario: Alfonso Núñez Navarro
Tesorero: Octavio Huerta Valdez
Todos los candidatos electos aceptan expresamente el cargo.
Siendo las 19:00 horas del día 31 de Diciembre del 2022 y habiéndose cumplimentado en su totalidad el Orden del Día previsto, se da por finalizada la Asamblea General. Se da lectura a esta Acta, y firman de conformidad los asambleístas designados, conjuntamente con el Presidente y el Consejo General, en el lugar y fecha indicados al inicio.
## **Firmas de los Presentes**
![](https://imgur.com/9ghNAPk.png)
______________________
Luis Alberto Saavedra Nieto.
![](https://i.imgur.com/xertJxD.png)
______________________
David E. Pérez Negron R.
![](https://i.imgur.com/8TbRdeR.png)
______________________
Omar Octavio Huerta Valdez.
![](https://i.imgur.com/UQD4ehY.png)
______________________
Christian Sandoval.
![](https://i.imgur.com/0LGljhs.png)
______________________
Alfonso Nuñez.
![](https://i.imgur.com/mXssbm0.png)
______________________
Marco Blanke.

View File

@ -1,402 +0,0 @@
---
eip: 1
title: EIP Purpose and Guidelines
status: Living
type: Meta
author: Martin Becze <mb@ethereum.org>, Hudson Jameson <hudson@ethereum.org>, et al.
created: 2015-10-27
---
## What is an EIP?
EIP stands for Ethereum Improvement Proposal. An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. The EIP should provide a concise technical specification of the feature and a rationale for the feature. The EIP author is responsible for building consensus within the community and documenting dissenting opinions.
## EIP Rationale
We intend EIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Ethereum. Because the EIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
For Ethereum implementers, EIPs are a convenient way to track the progress of their implementation. Ideally each implementation maintainer would list the EIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library.
## EIP Types
There are three types of EIP:
- A **Standards Track EIP** describes any change that affects most or all Ethereum implementations, such as—a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Standards Track EIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the [formal specification](https://github.com/ethereum/yellowpaper). Furthermore, Standards Track EIPs can be broken down into the following categories:
- **Core**: improvements requiring a consensus fork (e.g. [EIP-5](./eip-5.md), [EIP-101](./eip-101.md)), as well as changes that are not necessarily consensus critical but may be relevant to [“core dev” discussions](https://github.com/ethereum/pm) (for example, [EIP-90], and the miner/node strategy changes 2, 3, and 4 of [EIP-86](./eip-86.md)).
- **Networking**: includes improvements around [devp2p](https://github.com/ethereum/devp2p/blob/readme-spec-links/rlpx.md) ([EIP-8](./eip-8.md)) and [Light Ethereum Subprotocol](https://ethereum.org/en/developers/docs/nodes-and-clients/#light-node), as well as proposed improvements to network protocol specifications of [whisper](https://github.com/ethereum/go-ethereum/issues/16013#issuecomment-364639309) and [swarm](https://github.com/ethereum/go-ethereum/pull/2959).
- **Interface**: includes improvements around client [API/RPC](https://github.com/ethereum/execution-apis#README) specifications and standards, and also certain language-level standards like method names ([EIP-6](./eip-6.md)) and [contract ABIs](https://docs.soliditylang.org/en/develop/abi-spec.html). The label “interface” aligns with the [interfaces repo] and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.
- **ERC**: application-level standards and conventions, including contract standards such as token standards ([ERC-20](./eip-20.md)), name registries ([ERC-137](./eip-137.md)), URI schemes, library/package formats, and wallet formats.
- A **Meta EIP** describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.
- An **Informational EIP** describes an Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs or follow their advice.
It is highly recommended that a single EIP contain a single key proposal or new idea. The more focused the EIP, the more successful it tends to be. A change to one client doesn't require an EIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does.
An EIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.
### Special requirements for Core EIPs
If a **Core** EIP mentions or proposes changes to the EVM (Ethereum Virtual Machine), it should refer to the instructions by their mnemonics and define the opcodes of those mnemonics at least once. A preferred way is the following:
```
REVERT (0xfe)
```
## EIP Work Flow
### Shepherding an EIP
Parties involved in the process are you, the champion or *EIP author*, the [*EIP editors*](#eip-editors), and the [*Ethereum Core Developers*](https://github.com/ethereum/pm).
Before you begin writing a formal EIP, you should vet your idea. Ask the Ethereum community first if an idea is original to avoid wasting time on something that will be rejected based on prior research. It is thus recommended to open a discussion thread on [the Ethereum Magicians forum](https://ethereum-magicians.org/) to do this.
Once the idea has been vetted, your next responsibility will be to present (by means of an EIP) the idea to the reviewers and all interested parties, invite editors, developers, and the community to give feedback on the aforementioned channels. You should try and gauge whether the interest in your EIP is commensurate with both the work involved in implementing it and how many parties will have to conform to it. For example, the work required for implementing a Core EIP will be much greater than for an ERC and the EIP will need sufficient interest from the Ethereum client teams. Negative community feedback will be taken into consideration and may prevent your EIP from moving past the Draft stage.
### Core EIPs
For Core EIPs, given that they require client implementations to be considered **Final** (see "EIPs Process" below), you will need to either provide an implementation for clients or convince clients to implement your EIP.
The best way to get client implementers to review your EIP is to present it on an AllCoreDevs call. You can request to do so by posting a comment linking your EIP on an [AllCoreDevs agenda GitHub Issue](https://github.com/ethereum/pm/issues).
The AllCoreDevs call serves as a way for client implementers to do three things. First, to discuss the technical merits of EIPs. Second, to gauge what other clients will be implementing. Third, to coordinate EIP implementation for network upgrades.
These calls generally result in a "rough consensus" around what EIPs should be implemented. This "rough consensus" rests on the assumptions that EIPs are not contentious enough to cause a network split and that they are technically sound.
:warning: The EIPs process and AllCoreDevs call were not designed to address contentious non-technical issues, but, due to the lack of other ways to address these, often end up entangled in them. This puts the burden on client implementers to try and gauge community sentiment, which hinders the technical coordination function of EIPs and AllCoreDevs calls. If you are shepherding an EIP, you can make the process of building community consensus easier by making sure that [the Ethereum Magicians forum](https://ethereum-magicians.org/) thread for your EIP includes or links to as much of the community discussion as possible and that various stakeholders are well-represented.
*In short, your role as the champion is to write the EIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea.*
### EIP Process
The following is the standardization process for all EIPs in all tracks:
![EIP Status Diagram](../assets/eip-1/EIP-process-update.jpg)
**Idea** - An idea that is pre-draft. This is not tracked within the EIP Repository.
**Draft** - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.
**Review** - An EIP Author marks an EIP as ready for and requesting Peer Review.
**Last Call** - This is the final review window for an EIP before moving to `Final`. An EIP editor will assign `Last Call` status and set a review end date (`last-call-deadline`), typically 14 days later.
If this period results in necessary normative changes it will revert the EIP to `Review`.
**Final** - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.
A PR moving an EIP from Last Call to Final SHOULD contain no changes other than the status update. Any content or editorial proposed change SHOULD be separate from this status-updating PR and committed prior to it.
**Stagnant** - Any EIP in `Draft` or `Review` or `Last Call` if inactive for a period of 6 months or greater is moved to `Stagnant`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to `Draft` or it's earlier status. If not resurrected, a proposal may stay forever in this status.
>*EIP Authors are notified of any algorithmic change to the status of their EIP*
**Withdrawn** - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.
**Living** - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.
## What belongs in a successful EIP?
Each EIP should have the following parts:
- Preamble - RFC 822 style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See [below](./eip-1.md#eip-header-preamble) for details.
- Abstract - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.
- Motivation *(optional)* - A motivation section is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. This section may be omitted if the motivation is evident.
- Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (besu, erigon, ethereumjs, go-ethereum, nethermind, or others).
- 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 should discuss important objections or concerns raised during discussion around the EIP.
- Backwards Compatibility *(optional)* - All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their consequences. The EIP must explain how the author proposes to deal with these incompatibilities. This section may be omitted if the proposal does not introduce any backwards incompatibilities, but this section must be included if backward incompatibilities exist.
- Test Cases *(optional)* - Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Tests should either be inlined in the EIP as data (such as input/expected output pairs, or included in `../assets/eip-###/<filename>`. This section may be omitted for non-Core proposals.
- Reference Implementation *(optional)* - An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. This section may be omitted for all EIPs.
- Security Considerations - All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life-cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
- Copyright Waiver - All EIPs must be in the public domain. The copyright waiver MUST link to the license file and use the following wording: `Copyright and related rights waived via [CC0](../LICENSE.md).`
## EIP Formats and Templates
EIPs should be written in [markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) format. There is a [template](https://github.com/ethereum/EIPs/blob/master/eip-template.md) to follow.
## EIP Header Preamble
Each EIP must begin with an [RFC 822](https://www.ietf.org/rfc/rfc822.txt) style header preamble, preceded and followed by three hyphens (`---`). This header is also termed ["front matter" by Jekyll](https://jekyllrb.com/docs/front-matter/). The headers must appear in the following order.
`eip`: *EIP number* (this is determined by the EIP editor)
`title`: *The EIP title is a few words, not a complete sentence*
`description`: *Description is one full (short) sentence*
`author`: *The list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.*
`discussions-to`: *The url pointing to the official discussion thread*
`status`: *Draft, Review, Last Call, Final, Stagnant, Withdrawn, Living*
`last-call-deadline`: *The date last call period ends on* (Optional field, only needed when status is `Last Call`)
`type`: *One of `Standards Track`, `Meta`, or `Informational`*
`category`: *One of `Core`, `Networking`, `Interface`, or `ERC`* (Optional field, only needed for `Standards Track` EIPs)
`created`: *Date the EIP was created on*
`requires`: *EIP number(s)* (Optional field)
`withdrawal-reason`: *A sentence explaining why the EIP was withdrawn.* (Optional field, only needed when status is `Withdrawn`)
Headers that permit lists must separate elements with commas.
Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd).
### `author` header
The `author` header lists the names, email addresses or usernames of the authors/owners of the EIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the `author` header value must be:
> Random J. User &lt;address@dom.ain&gt;
or
> Random J. User (@username)
or
> Random J. User (@username) &lt;address@dom.ain&gt;
if the email address and/or GitHub username is included, and
> Random J. User
if neither the email address nor the GitHub username are given.
At least one author must use a GitHub username, in order to get notified on change requests and have the capability to approve or reject them.
### `discussions-to` header
While an EIP is a draft, a `discussions-to` header will indicate the URL where the EIP is being discussed.
The preferred discussion URL is a topic on [Ethereum Magicians](https://ethereum-magicians.org/). The URL cannot point to Github pull requests, any URL which is ephemeral, and any URL which can get locked over time (i.e. Reddit topics).
### `type` header
The `type` header specifies the type of EIP: Standards Track, Meta, or Informational. If the track is Standards please include the subcategory (core, networking, interface, or ERC).
### `category` header
The `category` header specifies the EIP's category. This is required for standards-track EIPs only.
### `created` header
The `created` header records the date that the EIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.
### `requires` header
EIPs may have a `requires` header, indicating the EIP numbers that this EIP depends on. If such a dependency exists, this field is required.
A `requires` dependency is created when the current EIP cannot be understood or implemented without a concept or technical element from another EIP. Merely mentioning another EIP does not necessarily create such a dependency.
## Linking to External Resources
Other than the specific exceptions listed below, links to external resources **SHOULD NOT** be included. External resources may disappear, move, or change unexpectedly.
The process governing permitted external resources is described in [EIP-5757](./eip-5757.md).
### Consensus Layer Specifications
Links to specific commits of files within the Ethereum Consensus Layer Specifications may be included using normal markdown syntax, such as:
```markdown
[Beacon Chain](https://github.com/ethereum/consensus-specs/blob/26695a9fdb747ecbe4f0bb9812fedbc402e5e18c/specs/sharding/beacon-chain.md)
```
Which renders to:
[Beacon Chain](https://github.com/ethereum/consensus-specs/blob/26695a9fdb747ecbe4f0bb9812fedbc402e5e18c/specs/sharding/beacon-chain.md)
Permitted Consensus Layer Specifications URLs must anchor to a specific commit, and so must match this regular expression:
```regex
^https://github.com/ethereum/consensus-specs/blob/[0-9a-f]{40}/.*$
```
### Networking Specifications
Links to specific commits of files within the Ethereum Networking Specifications may be included using normal markdown syntax, such as:
```markdown
[Ethereum Wire Protocol](https://github.com/ethereum/devp2p/blob/40ab248bf7e017e83cc9812a4e048446709623e8/caps/eth.md)
```
Which renders as:
[Ethereum Wire Protocol](https://github.com/ethereum/devp2p/blob/40ab248bf7e017e83cc9812a4e048446709623e8/caps/eth.md)
Permitted Networking Specifications URLs must anchor to a specific commit, and so must match this regular expression:
```regex
^https://github.com/ethereum/devp2p/blob/[0-9a-f]{40}/.*$
```
### Digital Object Identifier System
Links qualified with a Digital Object Identifier (DOI) may be included using the following syntax:
````markdown
This is a sentence with a footnote.[^1]
[^1]:
```csl-json
{
"type": "article",
"id": 1,
"author": [
{
"family": "Jameson",
"given": "Hudson"
}
],
"DOI": "00.0000/a00000-000-0000-y",
"title": "An Interesting Article",
"original-date": {
"date-parts": [
[2022, 12, 31]
]
},
"URL": "https://sly-hub.invalid/00.0000/a00000-000-0000-y",
"custom": {
"additional-urls": [
"https://example.com/an-interesting-article.pdf"
]
}
}
```
````
Which renders to:
<!-- markdownlint-capture -->
<!-- markdownlint-disable code-block-style -->
This is a sentence with a footnote.[^1]
[^1]:
```csl-json
{
"type": "article",
"id": 1,
"author": [
{
"family": "Jameson",
"given": "Hudson"
}
],
"DOI": "00.0000/a00000-000-0000-y",
"title": "An Interesting Article",
"original-date": {
"date-parts": [
[2022, 12, 31]
]
},
"URL": "https://sly-hub.invalid/00.0000/a00000-000-0000-y",
"custom": {
"additional-urls": [
"https://example.com/an-interesting-article.pdf"
]
}
}
```
<!-- markdownlint-restore -->
See the [Citation Style Language Schema](https://resource.citationstyles.org/schema/v1.0/input/json/csl-data.json) for the supported fields. In addition to passing validation against that schema, references must include a DOI and at least one URL.
The top-level URL field must resolve to a copy of the referenced document which can be viewed at zero cost. Values under `additional-urls` must also resolve to a copy of the referenced document, but may charge a fee.
## Linking to other EIPs
References to other EIPs should follow the format `EIP-N` where `N` is the EIP number you are referring to. Each EIP that is referenced in an EIP **MUST** be accompanied by a relative markdown link the first time it is referenced, and **MAY** be accompanied by a link on subsequent references. The link **MUST** always be done via relative paths so that the links work in this GitHub repository, forks of this repository, the main EIPs site, mirrors of the main EIP site, etc. For example, you would link to this EIP as `./eip-1.md`.
## Auxiliary Files
Images, diagrams and auxiliary files should be included in a subdirectory of the `assets` folder for that EIP as follows: `assets/eip-N` (where **N** is to be replaced with the EIP number). When linking to an image in the EIP, use relative links such as `../assets/eip-1/image.png`.
## Transferring EIP Ownership
It occasionally becomes necessary to transfer ownership of EIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred EIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the EIP process, or has fallen off the face of the 'net (i.e. is unreachable or isn't responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the EIP. We try to build consensus around an EIP, but if that's not possible, you can always submit a competing EIP.
If you are interested in assuming ownership of an EIP, send a message asking to take over, addressed to both the original author and the EIP editor. If the original author doesn't respond to the email in a timely manner, the EIP editor will make a unilateral decision (it's not like such decisions can't be reversed :)).
## EIP Editors
The current EIP editors are
- Alex Beregszaszi (@axic)
- Gavin John (@Pandapip1)
- Greg Colvin (@gcolvin)
- Matt Garnett (@lightclient)
- Sam Wilson (@SamWilsn)
- Zainan Victor Zhou (@xinbenlv)
- Gajinder Singh (@g11tech)
Emeritus EIP editors are
- Casey Detrio (@cdetrio)
- Hudson Jameson (@Souptacular)
- Martin Becze (@wanderer)
- Micah Zoltu (@MicahZoltu)
- Nick Johnson (@arachnid)
- Nick Savers (@nicksavers)
- Vitalik Buterin (@vbuterin)
If you would like to become an EIP editor, please check [EIP-5069](./eip-5069.md).
## EIP Editor Responsibilities
For each new EIP that comes in, an editor does the following:
- Read the EIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status.
- The title should accurately describe the content.
- Check the EIP for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), code style
If the EIP isn't ready, the editor will send it back to the author for revision, with specific instructions.
Once the EIP is ready for the repository, the EIP editor will:
- Assign an EIP number (generally the PR number, but the decision is with the editors)
- Merge the corresponding [pull request](https://github.com/ethereum/EIPs/pulls)
- Send a message back to the EIP author with the next step.
Many EIPs are written and maintained by developers with write access to the Ethereum codebase. The EIP editors monitor EIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.
The editors don't pass judgment on EIPs. We merely do the administrative & editorial part.
## Style Guide
### Titles
The `title` field in the preamble:
- Should not include the word "standard" or any variation thereof; and
- Should not include the EIP's number.
### Descriptions
The `description` field in the preamble:
- Should not include the word "standard" or any variation thereof; and
- Should not include the EIP's number.
### EIP numbers
When referring to an EIP with a `category` of `ERC`, it must be written in the hyphenated form `ERC-X` where `X` is that EIP's assigned number. When referring to EIPs with any other `category`, it must be written in the hyphenated form `EIP-X` where `X` is that EIP's assigned number.
### RFC 2119 and RFC 8174
EIPs are encouraged to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.html) and [RFC 8174](https://www.ietf.org/rfc/rfc8174.html) for terminology and to insert the following at the beginning of the Specification section:
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
## History
This document was derived heavily from [Bitcoin's BIP-0001](https://github.com/bitcoin/bips) written by Amir Taaki which in turn was derived from [Python's PEP-0001](https://peps.python.org/). In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Ethereum Improvement Process, and should not be bothered with technical questions specific to Ethereum or the EIP. Please direct all comments to the EIP editors.
## Copyright
Copyright and related rights waived via [CC0](../LICENSE.md).

View File

@ -1,66 +0,0 @@
---
eip: 2
title: Homestead Hard-fork Changes
author: Vitalik Buterin (@vbuterin)
status: Final
type: Standards Track
category: Core
created: 2015-11-15
---
### Meta reference
[Homestead](./eip-606.md).
### Parameters
| FORK_BLKNUM | CHAIN_NAME |
|-----------------|-------------|
| 1,150,000 | Main net |
| 494,000 | Morden |
| 0 | Future testnets |
# Specification
If `block.number >= HOMESTEAD_FORK_BLKNUM`, do the following:
1. The gas cost *for creating contracts via a transaction* is increased from 21,000 to 53,000, i.e. if you send a transaction and the to address is the empty string, the initial gas subtracted is 53,000 plus the gas cost of the tx data, rather than 21,000 as is currently the case. Contract creation from a contract using the `CREATE` opcode is unaffected.
2. All transaction signatures whose s-value is greater than `secp256k1n/2` are now considered invalid. The ECDSA recover precompiled contract remains unchanged and will keep accepting high s-values; this is useful e.g. if a contract recovers old Bitcoin signatures.
3. If contract creation does not have enough gas to pay for the final gas fee for adding the contract code to the state, the contract creation fails (i.e. goes out-of-gas) rather than leaving an empty contract.
4. Change the difficulty adjustment algorithm from the current formula: `block_diff = parent_diff + parent_diff // 2048 * (1 if block_timestamp - parent_timestamp < 13 else -1) + int(2**((block.number // 100000) - 2))` (where the `int(2**((block.number // 100000) - 2))` represents the exponential difficulty adjustment component) to `block_diff = parent_diff + parent_diff // 2048 * max(1 - (block_timestamp - parent_timestamp) // 10, -99) + int(2**((block.number // 100000) - 2))`, where `//` is the integer division operator, eg. `6 // 2 = 3`, `7 // 2 = 3`, `8 // 2 = 4`. The `minDifficulty` still defines the minimum difficulty allowed and no adjustment may take it below this.
# Rationale
Currently, there is an excess incentive to create contracts via transactions, where the cost is 21,000, rather than contracts, where the cost is 32,000. Additionally, with the help of suicide refunds, it is currently possible to make a simple ether value transfer using only 11,664 gas; the code for doing this is as follows:
```python
from ethereum import tester as t
> from ethereum import utils
> s = t.state()
> c = s.abi_contract('def init():\n suicide(0x47e25df8822538a8596b28c637896b4d143c351e)', endowment=10**15)
> s.block.get_receipts()[-1].gas_used
11664
> s.block.get_balance(utils.normalize_address(0x47e25df8822538a8596b28c637896b4d143c351e))
1000000000000000
```
This is not a particularly serious problem, but it is nevertheless arguably a bug.
Allowing transactions with any s value with `0 < s < secp256k1n`, as is currently the case, opens a transaction malleability concern, as one can take any transaction, flip the s value from `s` to `secp256k1n - s`, flip the v value (`27 -> 28`, `28 -> 27`), and the resulting signature would still be valid. This is not a serious security flaw, especially since Ethereum uses addresses and not transaction hashes as the input to an ether value transfer or other transaction, but it nevertheless creates a UI inconvenience as an attacker can cause the transaction that gets confirmed in a block to have a different hash from the transaction that any user sends, interfering with user interfaces that use transaction hashes as tracking IDs. Preventing high s values removes this problem.
Making contract creation go out-of-gas if there is not enough gas to pay for the final gas fee has the benefits that:
- (i) it creates a more intuitive "success or fail" distinction in the result of a contract creation process, rather than the current "success, fail, or empty contract" trichotomy;
- (ii) makes failures more easily detectable, as unless contract creation fully succeeds then no contract account will be created at all; and
- (iii) makes contract creation safer in the case where there is an endowment, as there is a guarantee that either the entire initiation process happens or the transaction fails and the endowment is refunded.
The difficulty adjustment change conclusively solves a problem that the Ethereum protocol saw two months ago where an excessive number of miners were mining blocks that contain a timestamp equal to `parent_timestamp + 1`; this skewed the block time distribution, and so the current block time algorithm, which targets a *median* of 13 seconds, continued to target the same median but the mean started increasing. If 51% of miners had started mining blocks in this way, the mean would have increased to infinity. The proposed new formula is roughly based on targeting the mean; one can prove that with the formula in use, an average block time longer than 24 seconds is mathematically impossible in the long term.
The use of `(block_timestamp - parent_timestamp) // 10` as the main input variable rather than the time difference directly serves to maintain the coarse-grained nature of the algorithm, preventing an excessive incentive to set the timestamp difference to exactly 1 in order to create a block that has slightly higher difficulty and that will thus be guaranteed to beat out any possible forks. The cap of -99 simply serves to ensure that the difficulty does not fall extremely far if two blocks happen to be very far apart in time due to a client security bug or other black-swan issue.
# Implementation
This is implemented in Python here:
1. https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/processblock.py#L130
2. https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/processblock.py#L129
3. https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/processblock.py#L304
4. https://github.com/ethereum/pyethereum/blob/d117c8f3fd93359fc641fd850fa799436f7c43b5/ethereum/blocks.py#L42

View File

@ -1,47 +0,0 @@
---
eip: 3
title: Addition of CALLDEPTH opcode
author: Martin Holst Swende <martin@swende.se>
status: Withdrawn
type: Standards Track
category: Core
created: 2015-11-19
---
# Abstract
This is a proposal to add a new opcode, `CALLDEPTH`. The `CALLDEPTH` opcode would return the remaining available call stack depth.
# Motivation
There is a limit specifying how deep contracts can call other contracts; the call stack. The limit is currently `256`. If a contract invokes another contract (either via `CALL` or `CALLCODE`), the operation will fail if the call stack depth limit has been reached.
This behaviour makes it possible to subject a contract to a "call stack attack" [1]. In such an attack, an attacker first creates a suitable depth of the stack, e.g. by recursive calls. After this step, the attacker invokes the targeted contract. If the targeted calls another contract, that call will fail. If the return value is not properly checked to see if the call was successful, the consequences could be damaging.
Example:
1. Contract `A` wants to be invoked regularly, and pays Ether to the invoker in every block.
2. When contract `A` is invoked, it calls contracts `B` and `C`, which consumes a lot of gas. After invocation, contract `A` pays Ether to the caller.
3. Malicious user `X` ensures that the stack depth is shallow before invoking A. Both calls to `B` and `C` fail, but `X` can still collect the reward.
It is possible to defend against this in two ways:
1. Check return value after invocation.
2. Check call stack depth experimentally. A library [2] by Piper Merriam exists for this purpose. This method is quite costly in gas.
[1] a.k.a "shallow stack attack" and "stack attack". However, to be precise, the word ''stack'' has a different meaning within the EVM, and is not to be confused with the ''call stack''.
[2] https://github.com/pipermerriam/ethereum-stack-depth-lib
# Specification
The opcode `CALLDEPTH` should return the remaining call stack depth. A value of `0` means that the call stack is exhausted, and no further calls can be made.
# Rationale
The actual call stack depth, as well as the call stack depth limit, are present in the EVM during execution, but just not available within the EVM. The implementation should be fairly simple and would provide a cheap and way to protect against call stack attacks.
# Implementation
Not implemented.

View File

@ -1,66 +0,0 @@
---
eip: 4
title: EIP Classification
author: Joseph Chow (@ethers)
status: Final
type: Meta
created: 2015-11-17
---
# Abstract
This document describes a classification scheme for EIPs, adapted from [BIP 123](https://github.com/bitcoin/bips/blob/master/bip-0123.mediawiki).
EIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements.
The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards EIP belongs.
# Motivation
Ethereum is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementors a choice of whether to support them.
In order to have a EIP process which more closely reflects the interoperability requirements, it is necessary to categorize EIPs accordingly. Lower layers present considerably greater challenges in getting standards accepted and deployed.
# Specification
Standards EIPs are placed in one of four layers:
1. Consensus
2. Networking
3. API/RPC
4. Applications
# 1. Consensus Layer
The consensus layer defines cryptographic commitment structures. Its purpose is ensuring that anyone can locally evaluate whether a particular state and history is valid, providing settlement guarantees, and assuring eventual convergence.
The consensus layer is not concerned with how messages are propagated on a network.
Disagreements over the consensus layer can result in network partitioning, or forks, where different nodes might end up accepting different incompatible histories. We further subdivide consensus layer changes into soft forks and hard forks.
## Soft Forks
In a soft fork, some structures that were valid under the old rules are no longer valid under the new rules. Structures that were invalid under the old rules continue to be invalid under the new rules.
## Hard Forks
In a hard fork, structures that were invalid under the old rules become valid under the new rules.
# 2. Networking Layer
The networking layer specifies the Ethereum wire protocol (eth) and the Light Ethereum Subprotocol (les). RLPx is excluded and tracked in the [https://github.com/ethereum/devp2p devp2p repository].
Only a subset of subprotocols are required for basic node interoperability. Nodes can support further optional extensions.
It is always possible to add new subprotocols without breaking compatibility with existing protocols, then gradually deprecate older protocols. In this manner, the entire network can be upgraded without serious risks of service disruption.
# 3. API/RPC Layer
The API/RPC layer specifies higher level calls accessible to applications. Support for these EIPs is not required for basic network interoperability but might be expected by some client applications.
There's room at this layer to allow for competing standards without breaking basic network interoperability.
# 4. Applications Layer
The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data.

View File

@ -1,121 +0,0 @@
---
eip: 5
title: Gas Usage for `RETURN` and `CALL*`
author: Christian Reitwiessner <c@ethdev.com>
status: Final
type: Standards Track
category: Core
created: 2015-11-22
---
### Abstract
This EIP makes it possible to call functions that return strings and other dynamically-sized arrays.
Currently, when another contract / function is called from inside the Ethereum Virtual Machine,
the size of the output has to be specified in advance. It is of course possible to give a larger
size, but gas also has to be paid for memory that is not written to, which makes returning
dynamically-sized data both costly and inflexible to the extent that it is actually unusable.
The solution proposed in this EIP is to charge gas only for memory that is actually written to at
the time the `CALL` returns.
### Specification
The gas and memory semantics for `CALL`, `CALLCODE` and `DELEGATECALL` (called later as `CALL*`)
are changed in the following way (`CREATE` does not write to memory and is thus unaffected):
Suppose the arguments to `CALL*` are `gas, address, value, input_start, input_size, output_start, output_size`,
then, at the beginning of the opcode, gas for growing memory is only charged for `input_start + input_size`, but not
for `output_start + output_size`.
If the called contract returns data of size `n`, the memory of the calling contract is grown to
`output_start + min(output_size, n)` (and the calling contract is charged gas for that) and the
output is written to the area `[output_start, output_start + min(n, output_size))`.
The calling contract can run out of gas both at the beginning of the opcode and at the end
of the opcode.
After the call, the `MSIZE` opcode should return the size the memory was actually grown to.
### Motivation
In general, it is good practise to reserve a certain memory area for the output of a call,
because letting a subroutine write to arbitrary areas in memory might be dangerous. On the
other hand, it is often hard to know the output size of a call prior to performing the call:
The data could be in the storage of another contract which is generally inaccessible and
determining its size would require another call to that contract.
Furthermore, charging gas for areas of memory that are not actually written to is unnecessary.
This proposal tries to solve both problems: A caller can choose to provide a gigantic area of
memory at the end of their memory area. The callee can "write" to it by returning and the
caller is only charged for the memory area that is actually written.
This makes it possible to return dynamic data like strings and dynamically-sized arrays
in a very flexible way. It is even possible to determine the size of the returned data:
If the caller uses `output_start = MSIZE` and `output_size = 2**256-1`, the area of
memory that was actually written to is `(output_start, MSIZE)` (here, `MSIZE` as evaluated
after the call). This is important because it allows "proxy" contracts
which call other contracts whose interface they do not know and just return their output,
i.e. they both forward the input and the output. For this, it is important that the caller
(1) does not need to know the size of the output in advance and (2) can determine the
size of the output after the call.
### Rationale
This way of dealing with the problem requires a minimal change to the Ethereum Virtual Machine.
Other means of achieving a similar goal would have changed the opcodes themselves or
the number of their arguments. Another possibility would have been to only change the
gas mechanics if `output_size` is equal to `2**256-1`. Since the main difficulty in the
implementation is that memory has to be enlarged at two points in the code around `CALL`,
this would not have been a simplification.
At an earlier stage, it was proposed to also add the size of the returned data on the stack,
but the `MSIZE` mechanism described above should be sufficient and is much better
backwards compatible.
Some comments are available at https://github.com/ethereum/EIPs/issues/8
### Backwards Compatibility
This proposal changes the semantics of contracts because contracts can access the gas counter
and the size of memory.
On the other hand, it is unlikely that existing contracts will suffer from this change due to
the following reasons:
Gas:
The VM will not charge more gas than before. Usually, contracts are written in a way such
that their semantics do not change if they use up less gas. If more gas were used, contracts
might go out-of-gas if they perform a tight estimation for gas needed by sub-calls. Here,
contracts might only return more gas to their callers.
Memory size:
The `MSIZE` opcode is typically used to allocate memory at a previously unused spot.
The change in semantics affects existing contracts in two ways:
1. Overlaps in allocated memory. By using `CALL`, a contract might have wanted to allocate
a certain slice of memory, even if that is not written to by the called contract.
Subsequent uses of `MSIZE` to allocate memory might overlap with this slice that is
now smaller than before the change. It is though unlikely that such contracts exist.
2. Memory addresses change. Rather general, if memory is allocated using `MSIZE`, the
addresses of objects in memory will be different after the change. Contract should
all be written in a way, though, such that objects in memory are _relocatable_,
i.e. their absolute position in memory and their relative position to other
objects does not matter. This is of course not the case for arrays, but they
are allocated in a single allocation and not with an intermediate `CALL`.
### Implementation
VM implementers should take care not to grow the memory until the end of the call and after a check that sufficient
gas is still available. Typical uses of the EIP include "reserving" `2**256-1` bytes of memory for the output.
Python implementation:
old: http://vitalik.ca/files/old.py
new: http://vitalik.ca/files/new.py

View File

@ -1,25 +0,0 @@
---
eip: 6
title: Renaming SUICIDE opcode
author: Hudson Jameson <hudson@hudsonjameson.com>
status: Final
type: Standards Track
category: Interface
created: 2015-11-22
---
### Abstract
The solution proposed in this EIP is to change the name of the `SUICIDE` opcode in Ethereum programming languages with `SELFDESTRUCT`.
### Motivation
Mental health is a very real issue for many people and small notions can make a difference. Those dealing with loss or depression would benefit from not seeing the word suicide in our programming languages. By some estimates, 350 million people worldwide suffer from depression. The semantics of Ethereum's programming languages need to be reviewed often if we wish to grow our ecosystem to all types of developers.
An Ethereum security audit commissioned by DEVolution, GmbH and [performed by Least Authority](https://github.com/LeastAuthority/ethereum-analyses/blob/master/README.md) recommended the following:
> Replace the instruction name "suicide" with a less connotative word like "self-destruct", "destroy", "terminate", or "close", especially since that is a term describing the natural conclusion of a contract.
The primary reason for us to change the term suicide is to show that people matter more than code and Ethereum is a mature enough of a project to recognize the need for a change. Suicide is a heavy subject and we should make every effort possible to not affect those in our development community who suffer from depression or who have recently lost someone to suicide. Ethereum is a young platform and it will cause less headaches if we implement this change early on in its life.
### Implementation
`SELFDESTRUCT` is added as an alias of `SUICIDE` opcode (rather than replacing it).
https://github.com/ethereum/solidity/commit/a8736b7b271dac117f15164cf4d2dfabcdd2c6fd
https://github.com/ethereum/serpent/commit/1106c3bdc8f1bd9ded58a452681788ff2e03ee7c

View File

@ -1,75 +0,0 @@
---
eip: 7
title: DELEGATECALL
author: Vitalik Buterin (@vbuterin)
status: Final
type: Standards Track
category: Core
created: 2015-11-15
---
### Hard Fork
[Homestead](./eip-606.md)
### Parameters
- Activation:
- Block >= 1,150,000 on Mainnet
- Block >= 494,000 on Morden
- Block >= 0 on future testnets
### Overview
Add a new opcode, `DELEGATECALL` at `0xf4`, which is similar in idea to `CALLCODE`, except that it propagates the sender and value from the parent scope to the child scope, i.e. the call created has the same sender and value as the original call.
### Specification
`DELEGATECALL`: `0xf4`, takes 6 operands:
- `gas`: the amount of gas the code may use in order to execute;
- `to`: the destination address whose code is to be executed;
- `in_offset`: the offset into memory of the input;
- `in_size`: the size of the input in bytes;
- `out_offset`: the offset into memory of the output;
- `out_size`: the size of the scratch pad for the output.
#### Notes on gas
- The basic stipend is not given; `gas` is the total amount the callee receives.
- Like `CALLCODE`, account creation never happens, so the upfront gas cost is always `schedule.callGas` + `gas`.
- Unused gas is refunded as normal.
#### Notes on sender
- `CALLER` and `VALUE` behave exactly in the callee's environment as they do in the caller's environment.
#### Other notes
- The depth limit of 1024 is still preserved as normal.
### Rationale
Propagating the sender and value from the parent scope to the child scope makes it much easier for a contract to store another address as a mutable source of code and ''pass through'' calls to it, as the child code would execute in essentially the same environment (except for reduced gas and increased callstack depth) as the parent.
Use case 1: split code to get around 3m gas barrier
```python
~calldatacopy(0, 0, ~calldatasize())
if ~calldataload(0) < 2**253:
~delegate_call(msg.gas - 10000, $ADDR1, 0, ~calldatasize(), ~calldatasize(), 10000)
~return(~calldatasize(), 10000)
elif ~calldataload(0) < 2**253 * 2:
~delegate_call(msg.gas - 10000, $ADDR2, 0, ~calldatasize(), ~calldatasize(), 10000)
~return(~calldatasize(), 10000)
...
```
Use case 2: mutable address for storing the code of a contract:
```python
if ~calldataload(0) / 2**224 == 0x12345678 and self.owner == msg.sender:
self.delegate = ~calldataload(4)
else:
~delegate_call(msg.gas - 10000, self.delegate, 0, ~calldatasize(), ~calldatasize(), 10000)
~return(~calldatasize(), 10000)
```
The child functions called by these methods can now freely reference `msg.sender` and `msg.value`.
### Possible arguments against
* You can replicate this functionality by just sticking the sender into the first twenty bytes of the call data. However, this would mean that code would need to be specially compiled for delegated contracts, and would not be usable in delegated and raw contexts at the same time.

View File

@ -1,388 +0,0 @@
---
eip: 8
title: devp2p Forward Compatibility Requirements for Homestead
author: Felix Lange <felix@ethdev.com>
status: Final
type: Standards Track
category: Networking
created: 2015-12-18
---
### Abstract
This EIP introduces new forward-compatibility requirements for implementations of the
devp2p Wire Protocol, the RLPx Discovery Protocol and the RLPx TCP Transport Protocol.
Clients which implement EIP-8 behave according to Postel's Law:
> Be conservative in what you do, be liberal in what you accept from others.
### Specification
Implementations of **the devp2p Wire Protocol** should ignore the version number of hello
packets. When sending the hello packet, the version element should be set to the highest
devp2p version supported. Implementations should also ignore any additional list elements
at the end of the hello packet.
Similarly, implementations of **the RLPx Discovery Protocol** should not validate the
version number of the ping packet, ignore any additional list elements in any packet, and
ignore any data after the first RLP value in any packet. Discovery packets with unknown
packet type should be discarded silently. The maximum size of any discovery packet is
still 1280 bytes.
Finally, implementations of **the RLPx TCP Transport protocol** should accept a new
encoding for the encrypted key establishment handshake packets. If an EIP-8 style RLPx
`auth-packet` is received, the corresponding `ack-packet` should be sent using the rules
below.
Decoding the RLP data in `auth-body` and `ack-body` should ignore mismatches of `auth-vsn`
and `ack-vsn`, any additional list elements and any trailing data after the list. During
the transitioning period (i.e. until the old format has been retired), implementations
should pad `auth-body` with at least 100 bytes of junk data. Adding a random amount in
range [100, 300] is recommended to vary the size of the packet.
```text
auth-vsn = 4
auth-size = size of enc-auth-body, encoded as a big-endian 16-bit integer
auth-body = rlp.list(sig, initiator-pubk, initiator-nonce, auth-vsn)
enc-auth-body = ecies.encrypt(recipient-pubk, auth-body, auth-size)
auth-packet = auth-size || enc-auth-body
ack-vsn = 4
ack-size = size of enc-ack-body, encoded as a big-endian 16-bit integer
ack-body = rlp.list(recipient-ephemeral-pubk, recipient-nonce, ack-vsn)
enc-ack-body = ecies.encrypt(initiator-pubk, ack-body, ack-size)
ack-packet = ack-size || enc-ack-body
where
X || Y
denotes concatenation of X and Y.
X[:N]
denotes an N-byte prefix of X.
rlp.list(X, Y, Z, ...)
denotes recursive encoding of [X, Y, Z, ...] as an RLP list.
sha3(MESSAGE)
is the Keccak256 hash function as used by Ethereum.
ecies.encrypt(PUBKEY, MESSAGE, AUTHDATA)
is the asymmetric authenticated encryption function as used by RLPx.
AUTHDATA is authenticated data which is not part of the resulting ciphertext,
but written to HMAC-256 before generating the message tag.
```
### Motivation
Changes to the devp2p protocols are hard to deploy because clients running an older
version will refuse communication if the version number or structure of the hello
(discovery ping, RLPx handshake) packet does not match local expectations.
Introducing forward-compatibility requirements as part of the Homestead consensus upgrade
will ensure that all client software in use on the Ethereum network can cope with future
network protocol upgrades (as long as backwards-compatibility is maintained).
### Rationale
The proposed changes address forward compatibility by applying Postel's Law (also known as
the Robustness Principle) throughout the protocol stack. The merit and applicability of
this approach has been studied repeatedly since its original application in RFC 761. For a
recent perspective, see
["The Robustness Principle Reconsidered" (Eric Allman, 2011)](https://queue.acm.org/detail.cfm?id=1999945).
#### Changes to the devp2p Wire Protocol
All clients currently contain statements such as the following:
```python
# pydevp2p/p2p_protocol.py
if data['version'] != proto.version:
log.debug('incompatible network protocols', peer=proto.peer,
expected=proto.version, received=data['version'])
return proto.send_disconnect(reason=reasons.incompatibel_p2p_version)
```
These checks make it impossible to change the version or structure of the hello packet.
Dropping them enables switching to a newer protocol version: Clients implementing a newer
version simply send a packet with higher version and possibly additional list elements.
* If such a packet is received by a node with lower version, it will blindly assume that
the remote end is backwards-compatible and respond with the old handshake.
* If the packet is received by a node with equal version, new features of the protocol can
be used.
* If the packet is received by a node with higher version, it can enable
backwards-compatibility logic or drop the connection.
#### Changes to the RLPx Discovery Protocol
The relaxation of discovery packet decoding rules largely codifies current practice. Most
existing implementations do not care about the number of list elements (an exception being
go-ethereum) and do not reject nodes with mismatching version. This behaviour is not
guaranteed by the spec, though.
If adopted, the change makes it possible to deploy protocol changes in a similar manner to
the devp2p hello change: simply bump the version and send additional information. Older
clients will ignore the additional elements and can continue to operate even when the
majority of the network has moved on to a newer protocol.
#### Changes to the RLPx TCP Handshake
Discussions of the RLPx v5 changes (chunked packets, change to key derivation) have
faltered in part because the v4 handshake encoding provides only one in-band way to add a
version number: shortening the random portion of the nonce. Even if the RLPx v5 handshake
proposal were accepted, future upgrades are hard because the handshake packet is a fixed
size ECIES ciphertext with known layout.
I propose the following changes to the handshake packets:
* Adding the length of the ciphertext as a plaintext header.
* Encoding the body of the handshake as RLP.
* Adding a version number to both packets in place of the token flag (unused).
* Removing the hash of the ephemeral public key (it is redundant).
These changes make it possible to upgrade the RLPx TCP transport protocol in the same
manner as described for the other protocols, i.e. by adding list elements and bumping the
version. Since this is the first change to the RLPx handshake packet, we can seize the
opportunity to remove all currently unused fields.
Additional data is permitted (and in fact required) after the RLP list because the
handshake packet needs to grow in order to be distinguishable from the old format.
Clients can employ logic such as the following pseudocode to handle both formats
simultaneously.
```go
packet = read(307, connection)
if decrypt(packet) {
// process as old format
} else {
size = unpack_16bit_big_endian(packet)
packet += read(size - 307 + 2, connection)
if !decrypt(packet) {
// error
}
// process as new format
}
```
The plain text size prefix is perhaps the most controversial aspect of this document. It
has been argued that the prefix aids adversaries that seek to filter and identify RLPx
connections on the network level.
This is largely a question of how much effort the adversary is willing to expense. If the
recommendation to randomise the lengths is followed, pure pattern-based packet
recognition is unlikely to succeed.
* For typical firewall operators, blocking all connections whose first two bytes form an
integer in range [300,600] is probably too invasive. Port-based blocking would be
a more effective measure to filter most RLPx traffic.
* For an attacker who can afford to correlate many criteria, the size prefix would ease
recognition because it adds to the indicator set. However, such an attacker could also
be expected to read or participate in RLPx Discovery traffic, which would be sufficient
to enable blocking of RLPx TCP connections whatever their format is.
### Backwards Compatibility
This EIP is backwards-compatible, all valid version 4 packets are still accepted.
### Implementation
[go-ethereum](https://github.com/ethereum/go-ethereum/pull/2091)
[libweb3core](https://github.com/ethereum/libweb3core/pull/46)
[pydevp2p](https://github.com/ethereum/pydevp2p/pull/32)
### Test Vectors
#### devp2p Base Protocol
devp2p hello packet advertising version 22 and containing a few additional list elements:
```text
f87137916b6e6574682f76302e39312f706c616e39cdc5836574683dc6846d6f726b1682270fb840
fda1cff674c90c9a197539fe3dfb53086ace64f83ed7c6eabec741f7f381cc803e52ab2cd55d5569
bce4347107a310dfd5f88a010cd2ffd1005ca406f1842877c883666f6f836261720304
```
#### RLPx Discovery Protocol
Implementations should accept the following encoded discovery packets as valid.
The packets are signed using the secp256k1 node key
```text
b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291
```
ping packet with version 4, additional list elements:
```text
e9614ccfd9fc3e74360018522d30e1419a143407ffcce748de3e22116b7e8dc92ff74788c0b6663a
aa3d67d641936511c8f8d6ad8698b820a7cf9e1be7155e9a241f556658c55428ec0563514365799a
4be2be5a685a80971ddcfa80cb422cdd0101ec04cb847f000001820cfa8215a8d790000000000000
000000000000000000018208ae820d058443b9a3550102
```
ping packet with version 555, additional list elements and additional random data:
```text
577be4349c4dd26768081f58de4c6f375a7a22f3f7adda654d1428637412c3d7fe917cadc56d4e5e
7ffae1dbe3efffb9849feb71b262de37977e7c7a44e677295680e9e38ab26bee2fcbae207fba3ff3
d74069a50b902a82c9903ed37cc993c50001f83e82022bd79020010db83c4d001500000000abcdef
12820cfa8215a8d79020010db885a308d313198a2e037073488208ae82823a8443b9a355c5010203
040531b9019afde696e582a78fa8d95ea13ce3297d4afb8ba6433e4154caa5ac6431af1b80ba7602
3fa4090c408f6b4bc3701562c031041d4702971d102c9ab7fa5eed4cd6bab8f7af956f7d565ee191
7084a95398b6a21eac920fe3dd1345ec0a7ef39367ee69ddf092cbfe5b93e5e568ebc491983c09c7
6d922dc3
```
pong packet with additional list elements and additional random data:
```text
09b2428d83348d27cdf7064ad9024f526cebc19e4958f0fdad87c15eb598dd61d08423e0bf66b206
9869e1724125f820d851c136684082774f870e614d95a2855d000f05d1648b2d5945470bc187c2d2
216fbe870f43ed0909009882e176a46b0102f846d79020010db885a308d313198a2e037073488208
ae82823aa0fbc914b16819237dcd8801d7e53f69e9719adecb3cc0e790c57e91ca4461c9548443b9
a355c6010203c2040506a0c969a58f6f9095004c0177a6b47f451530cab38966a25cca5cb58f0555
42124e
```
findnode packet with additional list elements and additional random data:
```text
c7c44041b9f7c7e41934417ebac9a8e1a4c6298f74553f2fcfdcae6ed6fe53163eb3d2b52e39fe91
831b8a927bf4fc222c3902202027e5e9eb812195f95d20061ef5cd31d502e47ecb61183f74a504fe
04c51e73df81f25c4d506b26db4517490103f84eb840ca634cae0d49acb401d8a4c6b6fe8c55b70d
115bf400769cc1400f3258cd31387574077f301b421bc84df7266c44e9e6d569fc56be0081290476
7bf5ccd1fc7f8443b9a35582999983999999280dc62cc8255c73471e0a61da0c89acdc0e035e260a
dd7fc0c04ad9ebf3919644c91cb247affc82b69bd2ca235c71eab8e49737c937a2c396
```
neighbours packet with additional list elements and additional random data:
```text
c679fc8fe0b8b12f06577f2e802d34f6fa257e6137a995f6f4cbfc9ee50ed3710faf6e66f932c4c8
d81d64343f429651328758b47d3dbc02c4042f0fff6946a50f4a49037a72bb550f3a7872363a83e1
b9ee6469856c24eb4ef80b7535bcf99c0004f9015bf90150f84d846321163782115c82115db84031
55e1427f85f10a5c9a7755877748041af1bcd8d474ec065eb33df57a97babf54bfd2103575fa8291
15d224c523596b401065a97f74010610fce76382c0bf32f84984010203040101b840312c55512422
cf9b8a4097e9a6ad79402e87a15ae909a4bfefa22398f03d20951933beea1e4dfa6f968212385e82
9f04c2d314fc2d4e255e0d3bc08792b069dbf8599020010db83c4d001500000000abcdef12820d05
820d05b84038643200b172dcfef857492156971f0e6aa2c538d8b74010f8e140811d53b98c765dd2
d96126051913f44582e8c199ad7c6d6819e9a56483f637feaac9448aacf8599020010db885a308d3
13198a2e037073488203e78203e8b8408dcab8618c3253b558d459da53bd8fa68935a719aff8b811
197101a4b2b47dd2d47295286fc00cc081bb542d760717d1bdd6bec2c37cd72eca367d6dd3b9df73
8443b9a355010203b525a138aa34383fec3d2719a0
```
#### RLPx Handshake
In these test vectors, node A initiates a connection with node B.
The values contained in all packets are given below:
```text
Static Key A: 49a7b37aa6f6645917e7b807e9d1c00d4fa71f18343b0d4122a4d2df64dd6fee
Static Key B: b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291
Ephemeral Key A: 869d6ecf5211f1cc60418a13b9d870b22959d0c16f02bec714c960dd2298a32d
Ephemeral Key B: e238eb8e04fee6511ab04c6dd3c89ce097b11f25d584863ac2b6d5b35b1847e4
Nonce A: 7e968bba13b6c50e2c4cd7f241cc0d64d1ac25c7f5952df231ac6a2bda8ee5d6
Nonce B: 559aead08264d5795d3909718cdd05abd49572e84fe55590eef31a88a08fdffd
```
(Auth₁) RLPx v4 format (sent from A to B):
```text
048ca79ad18e4b0659fab4853fe5bc58eb83992980f4c9cc147d2aa31532efd29a3d3dc6a3d89eaf
913150cfc777ce0ce4af2758bf4810235f6e6ceccfee1acc6b22c005e9e3a49d6448610a58e98744
ba3ac0399e82692d67c1f58849050b3024e21a52c9d3b01d871ff5f210817912773e610443a9ef14
2e91cdba0bd77b5fdf0769b05671fc35f83d83e4d3b0b000c6b2a1b1bba89e0fc51bf4e460df3105
c444f14be226458940d6061c296350937ffd5e3acaceeaaefd3c6f74be8e23e0f45163cc7ebd7622
0f0128410fd05250273156d548a414444ae2f7dea4dfca2d43c057adb701a715bf59f6fb66b2d1d2
0f2c703f851cbf5ac47396d9ca65b6260bd141ac4d53e2de585a73d1750780db4c9ee4cd4d225173
a4592ee77e2bd94d0be3691f3b406f9bba9b591fc63facc016bfa8
```
(Auth₂) EIP-8 format with version 4 and no additional list elements (sent from A to B):
```text
01b304ab7578555167be8154d5cc456f567d5ba302662433674222360f08d5f1534499d3678b513b
0fca474f3a514b18e75683032eb63fccb16c156dc6eb2c0b1593f0d84ac74f6e475f1b8d56116b84
9634a8c458705bf83a626ea0384d4d7341aae591fae42ce6bd5c850bfe0b999a694a49bbbaf3ef6c
da61110601d3b4c02ab6c30437257a6e0117792631a4b47c1d52fc0f8f89caadeb7d02770bf999cc
147d2df3b62e1ffb2c9d8c125a3984865356266bca11ce7d3a688663a51d82defaa8aad69da39ab6
d5470e81ec5f2a7a47fb865ff7cca21516f9299a07b1bc63ba56c7a1a892112841ca44b6e0034dee
70c9adabc15d76a54f443593fafdc3b27af8059703f88928e199cb122362a4b35f62386da7caad09
c001edaeb5f8a06d2b26fb6cb93c52a9fca51853b68193916982358fe1e5369e249875bb8d0d0ec3
6f917bc5e1eafd5896d46bd61ff23f1a863a8a8dcd54c7b109b771c8e61ec9c8908c733c0263440e
2aa067241aaa433f0bb053c7b31a838504b148f570c0ad62837129e547678c5190341e4f1693956c
3bf7678318e2d5b5340c9e488eefea198576344afbdf66db5f51204a6961a63ce072c8926c
```
(Auth₃) EIP-8 format with version 56 and 3 additional list elements (sent from A to B):
```text
01b8044c6c312173685d1edd268aa95e1d495474c6959bcdd10067ba4c9013df9e40ff45f5bfd6f7
2471f93a91b493f8e00abc4b80f682973de715d77ba3a005a242eb859f9a211d93a347fa64b597bf
280a6b88e26299cf263b01b8dfdb712278464fd1c25840b995e84d367d743f66c0e54a586725b7bb
f12acca27170ae3283c1073adda4b6d79f27656993aefccf16e0d0409fe07db2dc398a1b7e8ee93b
cd181485fd332f381d6a050fba4c7641a5112ac1b0b61168d20f01b479e19adf7fdbfa0905f63352
bfc7e23cf3357657455119d879c78d3cf8c8c06375f3f7d4861aa02a122467e069acaf513025ff19
6641f6d2810ce493f51bee9c966b15c5043505350392b57645385a18c78f14669cc4d960446c1757
1b7c5d725021babbcd786957f3d17089c084907bda22c2b2675b4378b114c601d858802a55345a15
116bc61da4193996187ed70d16730e9ae6b3bb8787ebcaea1871d850997ddc08b4f4ea668fbf3740
7ac044b55be0908ecb94d4ed172ece66fd31bfdadf2b97a8bc690163ee11f5b575a4b44e36e2bfb2
f0fce91676fd64c7773bac6a003f481fddd0bae0a1f31aa27504e2a533af4cef3b623f4791b2cca6
d490
```
(Ack₁) RLPx v4 format (sent from B to A):
```text
049f8abcfa9c0dc65b982e98af921bc0ba6e4243169348a236abe9df5f93aa69d99cadddaa387662
b0ff2c08e9006d5a11a278b1b3331e5aaabf0a32f01281b6f4ede0e09a2d5f585b26513cb794d963
5a57563921c04a9090b4f14ee42be1a5461049af4ea7a7f49bf4c97a352d39c8d02ee4acc416388c
1c66cec761d2bc1c72da6ba143477f049c9d2dde846c252c111b904f630ac98e51609b3b1f58168d
dca6505b7196532e5f85b259a20c45e1979491683fee108e9660edbf38f3add489ae73e3dda2c71b
d1497113d5c755e942d1
```
(Ack₂) EIP-8 format with version 4 and no additional list elements (sent from B to A):
```text
01ea0451958701280a56482929d3b0757da8f7fbe5286784beead59d95089c217c9b917788989470
b0e330cc6e4fb383c0340ed85fab836ec9fb8a49672712aeabbdfd1e837c1ff4cace34311cd7f4de
05d59279e3524ab26ef753a0095637ac88f2b499b9914b5f64e143eae548a1066e14cd2f4bd7f814
c4652f11b254f8a2d0191e2f5546fae6055694aed14d906df79ad3b407d94692694e259191cde171
ad542fc588fa2b7333313d82a9f887332f1dfc36cea03f831cb9a23fea05b33deb999e85489e645f
6aab1872475d488d7bd6c7c120caf28dbfc5d6833888155ed69d34dbdc39c1f299be1057810f34fb
e754d021bfca14dc989753d61c413d261934e1a9c67ee060a25eefb54e81a4d14baff922180c395d
3f998d70f46f6b58306f969627ae364497e73fc27f6d17ae45a413d322cb8814276be6ddd13b885b
201b943213656cde498fa0e9ddc8e0b8f8a53824fbd82254f3e2c17e8eaea009c38b4aa0a3f306e8
797db43c25d68e86f262e564086f59a2fc60511c42abfb3057c247a8a8fe4fb3ccbadde17514b7ac
8000cdb6a912778426260c47f38919a91f25f4b5ffb455d6aaaf150f7e5529c100ce62d6d92826a7
1778d809bdf60232ae21ce8a437eca8223f45ac37f6487452ce626f549b3b5fdee26afd2072e4bc7
5833c2464c805246155289f4
```
(Ack₃) EIP-8 format with version 57 and 3 additional list elements (sent from B to A):
```text
01f004076e58aae772bb101ab1a8e64e01ee96e64857ce82b1113817c6cdd52c09d26f7b90981cd7
ae835aeac72e1573b8a0225dd56d157a010846d888dac7464baf53f2ad4e3d584531fa203658fab0
3a06c9fd5e35737e417bc28c1cbf5e5dfc666de7090f69c3b29754725f84f75382891c561040ea1d
dc0d8f381ed1b9d0d4ad2a0ec021421d847820d6fa0ba66eaf58175f1b235e851c7e2124069fbc20
2888ddb3ac4d56bcbd1b9b7eab59e78f2e2d400905050f4a92dec1c4bdf797b3fc9b2f8e84a482f3
d800386186712dae00d5c386ec9387a5e9c9a1aca5a573ca91082c7d68421f388e79127a5177d4f8
590237364fd348c9611fa39f78dcdceee3f390f07991b7b47e1daa3ebcb6ccc9607811cb17ce51f1
c8c2c5098dbdd28fca547b3f58c01a424ac05f869f49c6a34672ea2cbbc558428aa1fe48bbfd6115
8b1b735a65d99f21e70dbc020bfdface9f724a0d1fb5895db971cc81aa7608baa0920abb0a565c9c
436e2fd13323428296c86385f2384e408a31e104670df0791d93e743a3a5194ee6b076fb6323ca59
3011b7348c16cf58f66b9633906ba54a2ee803187344b394f75dd2e663a57b956cb830dd7a908d4f
39a2336a61ef9fda549180d4ccde21514d117b6c6fd07a9102b5efe710a32af4eeacae2cb3b1dec0
35b9593b48b9d3ca4c13d245d5f04169b0b1
```
Node B derives the connection secrets for (Auth₂, Ack₂) as follows:
```text
aes-secret = 80e8632c05fed6fc2a13b0f8d31a3cf645366239170ea067065aba8e28bac487
mac-secret = 2ea74ec5dae199227dff1af715362700e989d889d7a493cb0639691efb8e5f98
```
Running B's `ingress-mac` keccak state on the string "foo" yields the hash
```text
ingress-mac("foo") = 0c7ec6340062cc46f5e9f1e3cf86f8c8c403c5a0964f5df0ebd34a75ddc86db5
```
### Copyright
Copyright and related rights waived via [CC0](../LICENSE.md).

View File

@ -2,14 +2,14 @@
The goal of the EIP project is to standardize and provide high-quality documentation for Ethereum itself and conventions built upon it. This repository tracks past and ongoing improvements to Ethereum in the form of Ethereum Improvement Proposals (EIPs). [EIP-1](https://eips.ethereum.org/EIPS/eip-1) governs how EIPs are published. The goal of the EIP project is to standardize and provide high-quality documentation for Ethereum itself and conventions built upon it. This repository tracks past and ongoing improvements to Ethereum in the form of Ethereum Improvement Proposals (EIPs). [EIP-1](https://eips.ethereum.org/EIPS/eip-1) governs how EIPs are published.
The [status page](https://eips.ethereum.org/) tracks and lists EIPs, which can be divided into the following categories: The [status page](https://dcips.decentralizedclimate.org/) tracks and lists EIPs, which can be divided into the following categories:
- [Core EIPs](https://eips.ethereum.org/core) are improvements to the Ethereum consensus protocol. - [Core EIPs](https://dcips.decentralizedclimate.org/core) are improvements to the Ethereum consensus protocol.
- [Networking EIPs](https://eips.ethereum.org/networking) specify the peer-to-peer networking layer of Ethereum. - [Networking EIPs](https://dcips.decentralizedclimate.org/networking) specify the peer-to-peer networking layer of Ethereum.
- [Interface EIPs](https://eips.ethereum.org/interface) standardize interfaces to Ethereum, which determine how users and applications interact with the blockchain. - [Interface EIPs](https://dcips.decentralizedclimate.org/interface) standardize interfaces to Ethereum, which determine how users and applications interact with the blockchain.
- [ERCs](https://eips.ethereum.org/erc) specify application layer standards, which determine how applications running on Ethereum can interact with each other. - [ERCs](https://dcips.decentralizedclimate.org/erc) specify application layer standards, which determine how applications running on Ethereum can interact with each other.
- [Meta EIPs](https://eips.ethereum.org/meta) are miscellaneous improvements that nonetheless require some sort of consensus. - [Meta EIPs](https://dcips.decentralizedclimate.org/meta) are miscellaneous improvements that nonetheless require some sort of consensus.
- [Informational EIPs](https://eips.ethereum.org/informational) are non-standard improvements that do not require any form of consensus. - [Informational EIPs](https://eips.decentralizedclimate.org/informational) are non-standard improvements that do not require any form of consensus.
**Before you write an EIP, ideas MUST be thoroughly discussed on [Ethereum Magicians](https://ethereum-magicians.org/) or [Ethereum Research](https://ethresear.ch/t/read-this-before-posting/8). Once consensus is reached, thoroughly read and review [EIP-1](https://eips.ethereum.org/EIPS/eip-1), which describes the EIP process.** **Before you write an EIP, ideas MUST be thoroughly discussed on [Ethereum Magicians](https://ethereum-magicians.org/) or [Ethereum Research](https://ethresear.ch/t/read-this-before-posting/8). Once consensus is reached, thoroughly read and review [EIP-1](https://eips.ethereum.org/EIPS/eip-1), which describes the EIP process.**

87
assets/do_di/AAGO.md Normal file
View File

@ -0,0 +1,87 @@
cta de Asamblea General Ordinaria N°1
## Decentralized Climate Foundation A.C.
En la Ciudad de México, Delegación Benito Juárez, a los 31 días del mes de Diciembre del año 2022, en el domicilio de la calle San Antonio Nº 123, Departamento 03, en las oficinas de la Decentralized Climate Foundation A.C., siendo las 17:00 horas, y habiéndose reunido el Quórum necesario conforme las directrices del Acta Constitutiva, se da comienzo a la Asamblea General Ordinaria, convocada por la Comisión Directiva, a fin de tratar el siguiente Orden del Día:
1) Lectura del Acta Constitutiva e Informe de Actividades Realizadas
2) Tratamiento y aprobación del Balance Anual correspondiente al primer año de actividades
3) Elección de los cargos Presidente y Secretario
4) Elección de los cargos de Tesorero
___
Esta Asamblea es presidida por el C. Luis Alberto Saavedra Nieto, Director y asistido por el Ing. David Pérez-Negron Rocha, fundador.
Se informa que se encuentra reunido el Quórum necesario para dar comienzo a la Asamblea con la presencia de la totalidad de sus asociados, según Planilla de Asistencia.
Acto seguido se pasa a tratar el **PRIMER PUNTO** del orden del día.
Luego de la lectura del Informe de Actividades Realizadas y después de un breve intercambio de opiniones se aprueba que los asociados designados para suscribir la presente Acta sean Luis Alberto Saavedra Nieto y David Perez-Negron Rocha.
A continuación se trata el **SEGUNDO PUNTO** del Orden del Día.
Luego de la escucha del Reporte un breve diálogo al respecto, la votación dio como resultado la **APROBACIÓN POR UNANIMIDAD** el Balance Anual tratado; quedando de esta manera aprobado por mayoría el Balance Anual.
Se pasa a tratar el **TERCER PUNTO** del Orden del Día.
Habiendo presentación de las Listas, se procede a su lectura. Luego de un breve debate e intercambio de opiniones entre los asociados, la votación dio como resultado la APROBACIÓN POR UNANIMIDAD de la Lista, se proponen como candidatos a las siguientes personas:
**Para el cargo de Secretario: el C. Alfonso Núñez Navarro
Para el cargo de Tesorero: el C. Omar Octavio Huerta Valdez**
Los asociados propuestos como candidatos aceptan su candidatura.
Luego de un breve debate e intercambio de opiniones la votación dio como resultado:
Para el cargo de Secretario, **4 votos para Alfonso Núñez Navarro, 1 abstención, 0 votos en contra.**
Se pasa a tratar el **PUNTO CUATRO** del Orden del Día.
Habiendo presentación de Listas, se procede a su lectura. Luego de un breve debate e intercambio de opiniones la votación dio como resultado la APROBACIÓN POR UNANIMIDAD de la Lista. Luego de un breve debate e intercambio de opiniones la votación dio como resultado:
Para el cargo de Tesorero, **4 votos para Omar Octavio Huerta Valdez, 1 abstención, 0 votos en contra.**
Finalmente se trata el **PUNTO QUINTO** del Orden del Día.
Los asociados propuestos como candidatos aceptan el cargo para el que fueron electos.
De esta forma se proclaman a las autoridades electas por el término de 5 años y contar desde el día de la fecha, con la siguiente conformación:
**Del Consejo General**
Secretario: Alfonso Núñez Navarro
Tesorero: Octavio Huerta Valdez
Todos los candidatos electos aceptan expresamente el cargo.
Siendo las 19:00 horas del día 31 de Diciembre del 2022 y habiéndose cumplimentado en su totalidad el Orden del Día previsto, se da por finalizada la Asamblea General. Se da lectura a esta Acta, y firman de conformidad los asambleístas designados, conjuntamente con el Presidente y el Consejo General, en el lugar y fecha indicados al inicio.
## **Firmas de los Presentes**
![](https://imgur.com/9ghNAPk.png)
______________________
Luis Alberto Saavedra Nieto.
![](https://i.imgur.com/xertJxD.png)
______________________
David E. Pérez Negron R.
![](https://i.imgur.com/8TbRdeR.png)
______________________
Omar Octavio Huerta Valdez.
![](https://i.imgur.com/UQD4ehY.png)
______________________
Christian Sandoval.
![](https://i.imgur.com/0LGljhs.png)
______________________
Alfonso Nuñez.
![](https://i.imgur.com/mXssbm0.png)
______________________
Marco Blanke.

View File

@ -1,107 +0,0 @@
[
{
"block_height": 30000,
"nonce": "123456789abcdef0",
"header_hash": "ffeeddccbbaa9988776655443322110000112233445566778899aabbccddeeff",
"mix_hash": "11f19805c58ab46610ff9c719dcf0a5f18fa2f1605798eef770c47219274767d",
"final_hash": "5b7ccd472dbefdd95b895cac8ece67ff0deb5a6bd2ecc6e162383d00c3728ece"
},
{
"block_height": 0,
"nonce": "0000000000000000",
"header_hash": "0000000000000000000000000000000000000000000000000000000000000000",
"mix_hash": "faeb1be51075b03a4ff44b335067951ead07a3b078539ace76fd56fc410557a3",
"final_hash": "63155f732f2bf556967f906155b510c917e48e99685ead76ea83f4eca03ab12b"
},
{
"block_height": 49,
"nonce": "0000000006ff2c47",
"header_hash": "63155f732f2bf556967f906155b510c917e48e99685ead76ea83f4eca03ab12b",
"mix_hash": "c789c1180f890ec555ff42042913465481e8e6bc512cb981e1c1108dc3f2227d",
"final_hash": "9e7248f20914913a73d80a70174c331b1d34f260535ac3631d770e656b5dd922"
},
{
"block_height": 50,
"nonce": "00000000076e482e",
"header_hash": "9e7248f20914913a73d80a70174c331b1d34f260535ac3631d770e656b5dd922",
"mix_hash": "c7340542c2a06b3a7dc7222635f7cd402abf8b528ae971ddac6bbe2b0c7cb518",
"final_hash": "de37e1824c86d35d154cf65a88de6d9286aec4f7f10c3fc9f0fa1bcc2687188d"
},
{
"block_height": 99,
"nonce": "000000003917afab",
"header_hash": "de37e1824c86d35d154cf65a88de6d9286aec4f7f10c3fc9f0fa1bcc2687188d",
"mix_hash": "f5e60b2c5bfddd136167a30cbc3c8dbdbd15a512257dee7964e0bc6daa9f8ba7",
"final_hash": "ac7b55e801511b77e11d52e9599206101550144525b5679f2dab19386f23dcce"
},
{
"block_height": 29950,
"nonce": "005d409dbc23a62a",
"header_hash": "ac7b55e801511b77e11d52e9599206101550144525b5679f2dab19386f23dcce",
"mix_hash": "07393d15805eb08ee6fc6cb3ad4ad1010533bd0ff92d6006850246829f18fd6e",
"final_hash": "e43d7e0bdc8a4a3f6e291a5ed790b9fa1a0948a2b9e33c844888690847de19f5"
},
{
"block_height": 29999,
"nonce": "005db5fa4c2a3d03",
"header_hash": "e43d7e0bdc8a4a3f6e291a5ed790b9fa1a0948a2b9e33c844888690847de19f5",
"mix_hash": "7551bddf977491da2f6cfc1679299544b23483e8f8ee0931c4c16a796558a0b8",
"final_hash": "d34519f72c97cae8892c277776259db3320820cb5279a299d0ef1e155e5c6454"
},
{
"block_height": 30000,
"nonce": "005db8607994ff30",
"header_hash": "d34519f72c97cae8892c277776259db3320820cb5279a299d0ef1e155e5c6454",
"mix_hash": "f1c2c7c32266af9635462e6ce1c98ebe4e7e3ecab7a38aaabfbf2e731e0fbff4",
"final_hash": "8b6ce5da0b06d18db7bd8492d9e5717f8b53e7e098d9fef7886d58a6e913ef64"
},
{
"block_height": 30049,
"nonce": "005e2e215a8ca2e7",
"header_hash": "8b6ce5da0b06d18db7bd8492d9e5717f8b53e7e098d9fef7886d58a6e913ef64",
"mix_hash": "57fe6a9fbf920b4e91deeb66cb0efa971e08229d1a160330e08da54af0689add",
"final_hash": "c2c46173481b9ced61123d2e293b42ede5a1b323210eb2a684df0874ffe09047"
},
{
"block_height": 30050,
"nonce": "005e30899481055e",
"header_hash": "c2c46173481b9ced61123d2e293b42ede5a1b323210eb2a684df0874ffe09047",
"mix_hash": "ba30c61cc5a2c74a5ecaf505965140a08f24a296d687e78720f0b48baf712f2d",
"final_hash": "ea42197eb2ba79c63cb5e655b8b1f612c5f08aae1a49ff236795a3516d87bc71"
},
{
"block_height": 30099,
"nonce": "005ea6aef136f88b",
"header_hash": "ea42197eb2ba79c63cb5e655b8b1f612c5f08aae1a49ff236795a3516d87bc71",
"mix_hash": "cfd5e46048cd133d40f261fe8704e51d3f497fc14203ac6a9ef6a0841780b1cd",
"final_hash": "49e15ba4bf501ce8fe8876101c808e24c69a859be15de554bf85dbc095491bd6"
},
{
"block_height": 59950,
"nonce": "02ebe0503bd7b1da",
"header_hash": "49e15ba4bf501ce8fe8876101c808e24c69a859be15de554bf85dbc095491bd6",
"mix_hash": "21511fbaa31fb9f5fc4998a754e97b3083a866f4de86fa7500a633346f56d773",
"final_hash": "f5c50ba5c0d6210ddb16250ec3efda178de857b2b1703d8d5403bd0f848e19cf"
},
{
"block_height": 59999,
"nonce": "02edb6275bd221e3",
"header_hash": "f5c50ba5c0d6210ddb16250ec3efda178de857b2b1703d8d5403bd0f848e19cf",
"mix_hash": "653eda37d337e39d311d22be9bbd3458d3abee4e643bee4a7280a6d08106ef98",
"final_hash": "341562d10d4afb706ec2c8d5537cb0c810de02b4ebb0a0eea5ae335af6fb2e88"
},
{
"block_height": 10000000,
"nonce": "005e30899481055e",
"header_hash": "efda178de857b2b1703d8d5403bd0f848e19cff5c50ba5c0d6210ddb16250ec3",
"mix_hash": "b2403f56c426177856eaf0eedd707c86ae78a432b9169c3689a67058fcf2a848",
"final_hash": "206aee640c0fd21473d5cc3654d63c80442d9e2dfa676d2801d3ec1fbab38a6d"
},
{
"block_height": 100000000,
"nonce": "02abe0589481055e",
"header_hash": "49e15ba4bf501ce8fe88765403bd0f848e19cff5c50ba5c0d6210ddb16250ec3",
"mix_hash": "ac452084d6f4e6eacf4282ad58dbd4ce7ef2653fb5e6b5c877f56928c907432a",
"final_hash": "b879f84923e71b812ef5a42ece0b5b9366c31cab218f40afe65f8a2cae448a6f"
}
]

View File

@ -1,108 +0,0 @@
[
{
"block_height": 30000,
"nonce": "123456789abcdef0",
"header_hash": "ffeeddccbbaa9988776655443322110000112233445566778899aabbccddeeff",
"mix_hash": "6018c151b0f9895ebe44a4ca6ce2829e5ba6ae1a68a4ccd05a67ac01219655c1",
"final_hash": "34d8436444aa5c61761ce0bcce0f11401df2eace77f5c14ba7039b86b5800c08"
},
{
"block_height": 0,
"nonce": "0000000000000000",
"header_hash": "0000000000000000000000000000000000000000000000000000000000000000",
"mix_hash": "f4ac202715ded4136e72887c39e63a4738331c57fd9eb79f6ec421c281aa8743",
"final_hash": "b3bad9ca6f7c566cf0377d1f8cce29d6516a96562c122d924626281ec948ef02"
},
{
"block_height": 49,
"nonce": "0000000006ff2c47",
"header_hash": "63155f732f2bf556967f906155b510c917e48e99685ead76ea83f4eca03ab12b",
"mix_hash": "8f744dec9140938453c8a502a489861aedec7e98ce7e11b10a3b661940c38786",
"final_hash": "ca0c365f1290ede4ee0d19cab08cd827030425ae8aba96b5248faafe732f1f80"
},
{
"block_height": 50,
"nonce": "00000000076e482e",
"header_hash": "9e7248f20914913a73d80a70174c331b1d34f260535ac3631d770e656b5dd922",
"mix_hash": "bd772e573609acead3b0f27d7935022ea0bf72f22ecf0980f0c21a74cc2fa3ef",
"final_hash": "75439f6c6e153d3c798309f01ba37e7a284d172f50841c7b523e81c1b8247083"
},
{
"block_height": 99,
"nonce": "000000003917afab",
"header_hash": "de37e1824c86d35d154cf65a88de6d9286aec4f7f10c3fc9f0fa1bcc2687188d",
"mix_hash": "18a5d2f1eaa3df5a54f254c3f90bfa8e40c63913664175c93a9e5136f4dc7c5c",
"final_hash": "2618185c024ad29fd75bc350da388cc0d47cdebbd6798400f17692a7ccf3314c"
},
{
"block_height": 29950,
"nonce": "005d409dbc23a62a",
"header_hash": "ac7b55e801511b77e11d52e9599206101550144525b5679f2dab19386f23dcce",
"mix_hash": "d98cd262f73f9e110d994e592ad793ffca5fa92d8aff0e6f40fe3e84940e09e5",
"final_hash": "8ec8a0486e759c59c6f7ba586450dc2a5c8c3586b52345efb9b604fa82f40f65"
},
{
"block_height": 29999,
"nonce": "005db5fa4c2a3d03",
"header_hash": "e43d7e0bdc8a4a3f6e291a5ed790b9fa1a0948a2b9e33c844888690847de19f5",
"mix_hash": "53979a1e55d7b1987664570920a3d9121052f06326b99c6698b38255ed419003",
"final_hash": "de03c1354159e07cf804ecc9a53f82b0187dd4a24837d20e56cae28b65c35eb0"
},
{
"block_height": 30000,
"nonce": "005db8607994ff30",
"header_hash": "d34519f72c97cae8892c277776259db3320820cb5279a299d0ef1e155e5c6454",
"mix_hash": "ec3eed8a744b1950ae72439e8d28a47b868f4cdc26e5c37084e441cceb289c21",
"final_hash": "a717a28081999625860cbb09262dbbcc6090427411a5a3c60fb86a0ded8d369e"
},
{
"block_height": 30049,
"nonce": "005e2e215a8ca2e7",
"header_hash": "8b6ce5da0b06d18db7bd8492d9e5717f8b53e7e098d9fef7886d58a6e913ef64",
"mix_hash": "ed3764d1cf0abc3798c594a372679dd076f7dda15b552e7ec83d3ba8b27cbe0c",
"final_hash": "dd85d293db9b1063c6428ac9ca74e8d5d4d9fee49e0123bafb914fa787f58e89"
},
{
"block_height": 30050,
"nonce": "005e30899481055e",
"header_hash": "c2c46173481b9ced61123d2e293b42ede5a1b323210eb2a684df0874ffe09047",
"mix_hash": "732a4c5f7de1cc6d2a3702e9ea717b4f9da0de66e75897a2d5dc6cf407e883fc",
"final_hash": "4e83a686a5390b8105a261c4c1480b23a17938d4d029d1239042be7515e980fa"
},
{
"block_height": 30099,
"nonce": "005ea6aef136f88b",
"header_hash": "ea42197eb2ba79c63cb5e655b8b1f612c5f08aae1a49ff236795a3516d87bc71",
"mix_hash": "be8789da582670b3b5091d3693b7584b5a554cd258c9a3f299645cfaf13acff9",
"final_hash": "72a6b01403faf90b2e74cb28920e953016d2c04f3e22d64aa4712ed00b5b6681"
},
{
"block_height": 59950,
"nonce": "02ebe0503bd7b1da",
"header_hash": "49e15ba4bf501ce8fe8876101c808e24c69a859be15de554bf85dbc095491bd6",
"mix_hash": "3d1093e05b7ac6f23bda5afecf36f01379f05df06a28bcefd3459b70941bbc41",
"final_hash": "56c9fefbfe93eac6de18b1bd4e42d6bf784f9dc5a112955d2ffa6d5fb3cc0657"
},
{
"block_height": 59999,
"nonce": "02edb6275bd221e3",
"header_hash": "f5c50ba5c0d6210ddb16250ec3efda178de857b2b1703d8d5403bd0f848e19cf",
"mix_hash": "855c62aba873a0955345556f2ba33cb1d74b7d42067402e6ec145dd031087b23",
"final_hash": "116053ccb7866e23df4263a359794fa84afceb0d11d97cb9389ffa763b7be43a"
},
{
"block_height": 10000000,
"nonce": "005e30899481055e",
"header_hash": "efda178de857b2b1703d8d5403bd0f848e19cff5c50ba5c0d6210ddb16250ec3",
"mix_hash": "3cb394b257046429e7a18528f2d1bc64e3b712031534ecb1f60f5c6d61fd60ca",
"final_hash": "5dca7eab5997b489420b5d05d56394b8be83824bcb5916b84d8b39d54186a6d6"
},
{
"block_height": 100000000,
"nonce": "02abe0589481055e",
"header_hash": "49e15ba4bf501ce8fe88765403bd0f848e19cff5c50ba5c0d6210ddb16250ec3",
"mix_hash": "cc8a24ce78d5df7787f7b47bad87c7ef5d4e159ba5d32d5d6b01a6c5c4a2b536",
"final_hash": "eba819f45d27b39cc0a8deb68b6dde03c37a9790634eeb6a1d0edb40ed26ee1d"
}
]

View File

@ -1,463 +0,0 @@
# Test Vectors for EIP-1057 - ProgPow
Many of these vectors are derived from [chfast/ethash](https://github.com/chfast/ethash)
## fnv1a
| `h` | `d` | _result_ |
| -----------: | -----------: | -----------: |
| `0X811C9DC5` | `0XDDD0A47B` | `0XD37EE61A` |
| `0XD37EE61A` | `0XEE304846` | `0XDEDC7AD4` |
| `0XDEDC7AD4` | `0X00000000` | `0XA9155BBC` |
## kiss99
For `z`=`362436069`, `w`=`521288629`, `jsr`=`123456789`, and `jcong`=`380116160` the result of each iterative call to `kiss99` is as follows:
| _iteration_ | _result_ |kernel
| ----------: | -----------: |
| `1` | `769445856` |
| `2` | `742012328` |
| `3` | `2121196314` |
| `4` | `2805620942` |
| `100000` | `941074834` |
## fill_mix
For `hash_seed`=`0xEE304846DDD0A47B` and `lane_id`=`0` the values stored in the `mix` array will be
> ```
> 0x10C02F0D, 0x99891C9E, 0xC59649A0, 0x43F0394D,
> 0x24D2BAE4, 0xC4E89D4C, 0x398AD25C, 0xF5C0E467,
> 0x7A3302D6, 0xE6245C6C, 0x760726D3, 0x1F322EE7,
> 0x85405811, 0xC2F1E765, 0xA0EB7045, 0xDA39E821,
> 0x79FC6A48, 0x089E401F, 0x8488779F, 0xD79E414F,
> 0x041A826B, 0x313C0D79, 0x10125A3C, 0x3F4BDFAC,
> 0xA7352F36, 0x7E70CB54, 0x3B0BB37D, 0x74A3E24A,
> 0xCC37236A, 0xA442B311, 0x955AB27A, 0x6D175B7E
> ```
For the same hash and `lane_id`=`13` the value in the `mix` array will be
> ```
> 0x4E46D05D, 0x2E77E734, 0x2C479399, 0x70712177,
> 0xA75D7FF5, 0xBEF18D17, 0x8D42252E, 0x35B4FA0E,
> 0x462C850A, 0x2DD2B5D5, 0x5F32B5EC, 0xED5D9EED,
> 0xF9E2685E, 0x1F29DC8E, 0xA78F098B, 0x86A8687B,
> 0xEA7A10E7, 0xBE732B9D, 0x4EEBCB60, 0x94DD7D97,
> 0x39A425E9, 0xC0E782BF, 0xBA7B870F, 0x4823FF60,
> 0xF97A5A1C, 0xB00BCAF4, 0x02D0F8C4, 0x28399214,
> 0xB4CCB32D, 0x83A09132, 0x27EA8279, 0x3837DDA3
> ```
## keccak_f800_progpow
Test case 1:
| | |
| -------- | ----------------------------------------------------------------------------------------------------------------- |
| header | `0xCCDDEEFF`, `0x8899AABB`, `0x44556677`, `0x00112233`,<br>`0x33221100`, `0x77665544`, `0xBBAA9988`, `0xFFEEDDCC` |
| seed | `0x123456789ABCDEF0` |
| digest | `0x00000000`, `0x00000000`, `0x00000000`, `0x00000000`,<br>`0x00000000`, `0x00000000`, `0x00000000`, `0x00000000` |
| _result_ | `0x464830EE`, `0x7BA4D0DD`, `0x969E1798`, `0xCEC50EB6`,<br>`0x7872E2EA`, `0x597E3634`, `0xE380E73D`, `0x2F89D1E6` |
Test case 2:
| | |
| -------- | ----------------------------------------------------------------------------------------------------------------- |
| header | `0xCCDDEEFF`, `0x8899AABB`, `0x44556677`, `0x00112233`,<br>`0x33221100`, `0x77665544`, `0xBBAA9988`, `0xFFEEDDCC` |
| seed | `0xEE304846DDD0A47B` |
| digest | `0x0598F111`, `0x66B48AC5`, `0x719CFF10`, `0x5F0ACF9D`,<br>`0x162FFA18`, `0xEF8E7905`, `0x21470C77`, `0x7D767492` |
| _result_ | `0x47CD7C5B`, `0xD9FDBE2D`, `0xAC5C895B`, `0xFF67CE8E`,<br>`0x6B5AEB0D`, `0xE1C6ECD2`, `0x003D3862`, `0xCE8E72C3` |
## progPowInit
For ProgPow period 600 (block 30,000) the configurations should be
src array:
> `0x1A`, `0x1E`, `0x01`, `0x13`, `0x0B`, `0x15`, `0x0F`, `0x12`,
> `0x03`, `0x11`, `0x1F`, `0x10`, `0x1C`, `0x04`, `0x16`, `0x17`,
> `0x02`, `0x0D`, `0x1D`, `0x18`, `0x0A`, `0x0C`, `0x05`, `0x14`,
> `0x07`, `0x08`, `0x0E`, `0x1B`, `0x06`, `0x19`, `0x09`, `0x00`
dst array
> `0x00`, `0x04`, `0x1B`, `0x1A`, `0x0D`, `0x0F`, `0x11`, `0x07`,
> `0x0E`, `0x08`, `0x09`, `0x0C`, `0x03`, `0x0A`, `0x01`, `0x0B`,
> `0x06`, `0x10`, `0x1C`, `0x1F`, `0x02`, `0x13`, `0x1E`, `0x16`,
> `0x1D`, `0x05`, `0x18`, `0x12`, `0x19`, `0x17`, `0x15`, `0x14`
Kiss 99 state:
`z`=`0x6535921C` `w`=`0x29345B16`, `jsr`=`0xC0DD7F78`, `jcong`=`0x1165D7EB`
## merge
| `a` | `b` | `r` | _result_ | _path exercised_ |
| ------------ | ------------ | ------------ | ------------ | ---------------- |
| `0x3B0BB37D` | `0xA0212004` | `0x9BD26AB0` | `0x3CA34321` | mul/add |
| `0x10C02F0D` | `0x870FA227` | `0xD4F45515` | `0x91C1326A` | xor/mul |
| `0x24D2BAE4` | `0x0FFB4C9B` | `0x7FDBC2F2` | `0x2EDDD94C` | rotl/xor |
| `0xDA39E821` | `0x089C4008` | `0x8B6CD8C3` | `0x8A81E396` | rotr/xor |
## math
| `a` | `b` | `r` | _result_ | _operation exercised_ |
| ------------ | ------------ | ------------ | ------------ | ----------------------- |
| `0x8626BB1F` | `0xBBDFBC4E` | `0x883E5B49` | `0x4206776D` | add |
| `0x3F4BDFAC` | `0xD79E414F` | `0x36B71236` | `0x4C5CB214` | mul |
| `0x6D175B7E` | `0xC4E89D4C` | `0x944ECABB` | `0x53E9023F` | mul_hi32 |
| `0x2EDDD94C` | `0x7E70CB54` | `0x3F472A85` | `0x2EDDD94C` | min |
| `0x61AE0E62` | `0xe0596b32` | `0x3F472A85` | `0x61AE0E62` | min again (unsigned) |
| `0x8A81E396` | `0x3F4BDFAC` | `0xCEC46E67` | `0x1E3968A8` | rotl32 |
| `0x8A81E396` | `0x7E70CB54` | `0xDBE71FF7` | `0x1E3968A8` | rotr32 |
| `0xA7352F36` | `0xA0EB7045` | `0x59E7B9D8` | `0xA0212004` | bitwise and |
| `0xC89805AF` | `0x64291E2F` | `0x1BDC84A9` | `0xECB91FAF` | bitwise or |
| `0x760726D3` | `0x79FC6A48` | `0xC675CAC5` | `0x0FFB4C9B` | bitwise xor |
| `0x75551D43` | `0x3383BA34` | `0x2863AD31` | `0x00000003` | clz (leading zeros) |
| `0xEA260841` | `0xE92C44B7` | `0xF83FFE7D` | `0x0000001B` | popcount (number of 1s) |
## progPowLoop
For the first loop iteration of block 30,000 the seed to use for `fill_mix`
would be `0xEE304846DDD0A47B`. A two dimensional `mix` array should be created
passing the rows into `fill_mix` with the column number as the loop argument.
The state of the mix array after the call to `progPowLoop` for block 30,000,
loop 1 are as follows.
`mix[0]` -
> ```
> 0x40E09E9C, 0x967A7DF0, 0x8626BB1F, 0x12C2392F,
> 0xA21D8305, 0x44C2702E, 0x94C93945, 0x6B66B158,
> 0x0CF00FAA, 0x26F5E6B5, 0x36EC0134, 0xC89805AF,
> 0x58118540, 0x8617DC4D, 0xC759F486, 0x8A81E396,
> 0x22443D4D, 0x64291E2F, 0x1998AB7F, 0x11C0FBBB,
> 0xBEA9C139, 0x82D1E47E, 0x7ED3E850, 0x2F81531A,
> 0xBBDFBC4E, 0xF58AEE4D, 0x3CA34321, 0x357BD48A,
> 0x2F9C8B5D, 0x2319B193, 0x2856BB38, 0x2E3C33E6
> ```
`mix[1]` -
> ```
> 0x4EB8A8F9, 0xD978BF17, 0x7D5074D4, 0x7A092D5D,
> 0x8682D1BE, 0xC3D2941C, 0xF1A1A38B, 0x54BB6D34,
> 0x2F0FB257, 0xB5464B50, 0x40927B67, 0xBB92A7E1,
> 0x1305A517, 0xE06C6765, 0xA75FD647, 0x9F232D6E,
> 0x0D9213ED, 0x8884671D, 0x54352B96, 0x6772E58E,
> 0x1B8120C9, 0x179F3CFB, 0x116FFC82, 0x6D019BCE,
> 0x1C26A750, 0x89716638, 0x02BEB948, 0x2E0AD5CE,
> 0x7FA915B2, 0x93024F2F, 0x2F58032E, 0xF02E550C
> ```
`mix[2]` -
> ```
> 0x008FF9BD, 0xC41F9802, 0x2E36FDC8, 0x9FBA2A91,
> 0x0A921670, 0x231308E6, 0xEF09A56E, 0x9657A64A,
> 0xF67723FE, 0x963DCD40, 0x354CBFDB, 0x57C07B9A,
> 0x06AF5B40, 0xBA5DE5A6, 0xDA5AAE7B, 0x9F8A5E4B,
> 0x7D6AFC9A, 0xE4783F78, 0x89B24946, 0x5EE94228,
> 0xA209DAAA, 0xDCC27C64, 0x3366FBED, 0x0FEFB673,
> 0x0FC205E3, 0xB61515B2, 0x70A45E9B, 0xBB225E5D,
> 0xB8C38EA0, 0xE01DE9B4, 0x866FAA5B, 0x1A125220
> ```
`mix[3]` -
> ```
> 0xE5F9C5CC, 0x6F75CFA2, 0xE0F50924, 0xE7B4F5EF,
> 0x779B903D, 0x5F068253, 0x05FF68E5, 0x39348653,
> 0x654B89E4, 0x0559769E, 0xA3D46B93, 0xD084454D,
> 0xCFC5CF7D, 0x8C11D8E4, 0x795BDB59, 0xD9E03113,
> 0xBAE8C355, 0x12B63814, 0x4046A018, 0xA269A32E,
> 0x54A57C4B, 0x2ED1065B, 0xB69A2C76, 0x4AEF0950,
> 0x6C2D187B, 0x8252FAE7, 0x3E9C0ED2, 0x26E47B15,
> 0xFEFB48E3, 0xDA088C7F, 0xA82B0379, 0xA49C6D86
> ```
`mix[4]` -
> ```
> 0xB926334C, 0x686A29AF, 0xD9E2EF15, 0x1C8A2D39,
> 0x307ED4F4, 0x2ABB1DB6, 0xD6F95128, 0xDFCA05F8,
> 0x904D9472, 0xEC09E200, 0x7143F47F, 0xEE488438,
> 0xFCA48DA8, 0xA64C7DD4, 0xC4AE9A30, 0xEBA30BC9,
> 0xB02630BF, 0xD1DF40CC, 0x4DFE8B7B, 0x205C97B3,
> 0xE40376F8, 0x2491117E, 0x34984321, 0xA01546A7,
> 0xB254F2F9, 0xC78A7C25, 0xFFC615E2, 0x5839FC88,
> 0x2A04DF6C, 0xC02A9A8A, 0x39238EAD, 0x7139060C
> ```
`mix[5]` -
> ```
> 0xC416E54B, 0x64AD1C57, 0xBF7CBA55, 0x176F714E,
> 0xBE733426, 0x995C4132, 0x5F50F779, 0x0F76FDF3,
> 0x526F7870, 0xE56A1A8A, 0xDCEB677E, 0xD471CC19,
> 0xA9ED60E4, 0x145E807F, 0x8D652E92, 0x80E8116F,
> 0xFF1A37EB, 0x1E0C49A1, 0x59D756DA, 0x39A8E761,
> 0x2F0F646F, 0x43F41278, 0x88CC48DA, 0x8FDFF7A4,
> 0x9AEACA2E, 0x59E7808C, 0x7F72E46B, 0xCA572333,
> 0xC6029C88, 0x7736E592, 0xF1338231, 0x262B2C7F
> ```
`mix[6]` -
> ```
> 0x3C554151, 0x70999423, 0x64BB49A8, 0xF9EBE9E9,
> 0x7D9C28CF, 0x23EE7659, 0xD6504FCF, 0x1C58C2A1,
> 0x62B9C627, 0x680AE248, 0xF196A153, 0x2A3C345A,
> 0x860E6EB2, 0x266D2652, 0x3C9F2420, 0xF790A538,
> 0x710A5523, 0xBEA2603A, 0x1C1CC272, 0xF91D482A,
> 0x1CA19931, 0x7A80ED37, 0x9572513D, 0x376F1CFE,
> 0xE57C1264, 0xE47BF931, 0xC7310E05, 0x7866CC9E,
> 0xC676BBD5, 0x4C167FEB, 0x0FE03D2B, 0x46C6D26C
> ```
`mix[7]` -
> ```
> 0x3395F65A, 0x7142A5B1, 0x97780661, 0xE5EE45B8,
> 0xCD9FDC42, 0x25BF044C, 0x0350F81B, 0x55D50703,
> 0xA8CB893E, 0xEE795201, 0xC2D6E598, 0xC2AC2D7A,
> 0xD2E81716, 0xAD876790, 0x0F3339C7, 0xEEC31E01,
> 0xA293ABF6, 0x28AE317D, 0x44A7AC05, 0xBEBA1C5E,
> 0x325ED29E, 0x4344131E, 0x921CD8DD, 0x08AB9E0B,
> 0xC18E66A6, 0x87E6BCA3, 0x24CE82AE, 0xC910B4F1,
> 0x9E513EC0, 0xA1B8CB76, 0xF0455815, 0x36BC0DCF
> ```
`mix[8]` -
> ```
> 0x0117C85F, 0xE018F2C6, 0x416C897D, 0x9D288A0F,
> 0x2AA9EA93, 0x5A6D3CEA, 0xAA99B726, 0x0A42DAB7,
> 0x72F6EA4A, 0x1DB074E6, 0x2E2A606C, 0xAC5D509B,
> 0x53F13E85, 0x1D44B521, 0x24234C42, 0xAD5BAD70,
> 0xAB2DA791, 0x6479546A, 0xD27B3771, 0xBB0A09DD,
> 0x6D3C8056, 0x96572D4B, 0x52DB6535, 0x3D242BC1,
> 0xF37D7C7A, 0xA60F7111, 0x59B59667, 0xF28635B0,
> 0xC2A8F9F5, 0x7CFB9CCB, 0xDF8697AA, 0xA3260D94
> ```
`mix[9]` -
> ```
> 0xA387FC4B, 0xC757D3A0, 0xA584E879, 0xB0A1EC29,
> 0x82CB2EC3, 0x6BF33664, 0x41FECC42, 0xF60C2AC5,
> 0xEA250BE5, 0x42BE9F33, 0x9227B0B3, 0x9080A6AB,
> 0xAF193598, 0xC708BC8A, 0x020CDEDB, 0x7FA2F773,
> 0x4338E670, 0x069E0242, 0x5AD87326, 0xD7A87124,
> 0x220D5C46, 0x26D3400D, 0x4899D1EE, 0x90EAD2F6,
> 0xFA3F1F74, 0x9C5A5D58, 0xAE20567C, 0x424B690D,
> 0xC9A4057A, 0x9F2A5CD1, 0xAA33CD5F, 0x18F58C00
> ```
`mix[10]` -
> ```
> 0xEAFE893C, 0x1ABB2971, 0x29803BB3, 0x5BC2F71F,
> 0x619DAFAD, 0xD9CFEFB6, 0xB4FEFAB5, 0x5EB249EC,
> 0x1A6E2B3A, 0xFB05DD28, 0xDCB33C2E, 0x630BB8AE,
> 0x43463B39, 0x3BD2F552, 0xFB20C0A2, 0x3383BA34,
> 0x2E9C1A99, 0x60A949B2, 0x861372AB, 0xC149D929,
> 0xA77A0A93, 0xE0CEE0D9, 0x791E7E82, 0x66A8D75A,
> 0x44D1845F, 0xE534DC4A, 0x2C7DD20C, 0xEEDAB329,
> 0x3209FE2A, 0x0C0406BC, 0xD6D4BD2A, 0x5FDB13CC
> ```
`mix[11]` -
> ```
> 0x2520ABB3, 0xCD942485, 0x9A2929BC, 0x0E10F18C,
> 0xDFB1815E, 0x8BEF05A3, 0x531A8837, 0x668838E4,
> 0xBACCE200, 0x003F85C2, 0x56226F05, 0xC2233173,
> 0x2F39A0D9, 0xF4466D0D, 0x0B9E686C, 0x82C69BDA,
> 0x0C8A8CD6, 0xA93F3001, 0x36A65EC1, 0x40CCFD7A,
> 0x84484E23, 0xF0896D45, 0x06D9F760, 0x6559142C,
> 0x9FFE2E88, 0x9593DC89, 0x89C9E3B9, 0x33285F41,
> 0x16F636C8, 0xA08169C7, 0xA5E1C956, 0xC22CCF52
> ```
`mix[12]` -
> ```
> 0xDC3B8CAA, 0xC6941197, 0x9969D596, 0x46453D3E,
> 0x568EAFEA, 0x5B823345, 0xDE606E8E, 0x7523C86D,
> 0x0EDAF441, 0x00C3D848, 0xAE5BAB99, 0xD705B9EE,
> 0x54B49E3D, 0xF364A6A4, 0x42C55975, 0xFE41EED5,
> 0xAD46170F, 0xAABE4868, 0x270379F9, 0xD33D0D7C,
> 0xF39C476C, 0xA449118E, 0x71BCC1E4, 0x5E300E77,
> 0x1CACD489, 0x4D82FABD, 0x090F9F80, 0xB2DB9626,
> 0xE12A973B, 0x1B77460C, 0xD25F89F5, 0x5753612E
> ```
`mix[13]` -
> ```
> 0x042D951C, 0x38833AA7, 0xBEA9894D, 0x7AE7F381,
> 0x42DB6723, 0x1FB0294F, 0x41452A28, 0xA7A97B9C,
> 0x228AA7EA, 0x781A7420, 0x4589736D, 0xB3C19349,
> 0x685EF9E6, 0xB4987DF6, 0xC9C3B188, 0x2DCA6A03,
> 0xE89A6D3D, 0x50EF7CF5, 0xF6274868, 0x8AA22824,
> 0x980FFDE3, 0xD4A6CB4E, 0x06FF9E1A, 0xBADB6DF5,
> 0xEDE3ADF3, 0xC9CF45F6, 0xFDFA194C, 0xAF076AA8,
> 0x7B876CEA, 0xB0C89575, 0x35A72155, 0x6CFDFC06
> ```
`mix[14]` -
> ```
> 0x0E3E28C8, 0xEC329DEC, 0x06D0A1D1, 0xF95ABEF8,
> 0x168DCF28, 0xDD7714C1, 0x769C119E, 0xA5530A7D,
> 0x1EEACB59, 0x30FD21BB, 0x082A3691, 0x1C4C9BCA,
> 0x420F27DE, 0xA8FDA3AE, 0xE182142E, 0x5102F0FF,
> 0x15B82277, 0x120C3217, 0x7BE714ED, 0xA251DCD5,
> 0x6FB4F831, 0xB71D7B32, 0xD5F7A04A, 0x763E1A20,
> 0x38E68B0C, 0xBB5A4121, 0x9340BF06, 0x948B03F8,
> 0xE71BF17B, 0x1BB5F06B, 0x26F2A200, 0x5F28C415
> ```
`mix[15]` -
> ```
> 0xC818CD64, 0xBC910343, 0xB18B7776, 0x7182DEBA,
> 0x9DB319EE, 0x9AE7F32F, 0x3CA9F8B5, 0xC63F48ED,
> 0x8321533A, 0x059C96B1, 0x8DCDA60A, 0x75B6C1D1,
> 0xC3406B57, 0x3DFE9E9B, 0xC01E1FD7, 0xC4643218,
> 0x6873F0BA, 0x8ABD36B9, 0xA74D0CBD, 0x8A637118,
> 0x6916416C, 0xB6E3A8DD, 0xB68DD4FA, 0xFBD543EE,
> 0x56F05592, 0x33D6DB82, 0x58D0A7DD, 0x18630C6E,
> 0xB33749CA, 0x5D2E87F7, 0x0F3C39DB, 0x3CAE9895
> ```
## progPowHash
### 0.9.2
[Machine-readable data](https://github.com/ethereum/EIPs/blob/ad4e73f239d53d72a21cfd8fdc89dc81eb9d2688/assets/eip-1057/test-vectors-0.9.3.json)
Block 30000:
- `prog_seed` - 600
- `nonce` - `123456789abcdef0`
- `header` - `ffeeddccbbaa9988776655443322110000112233445566778899aabbccddeeff`
- `mix_hash` - `11f19805c58ab46610ff9c719dcf0a5f18fa2f1605798eef770c47219274767d`
- `final_hash` - `5b7ccd472dbefdd95b895cac8ece67ff0deb5a6bd2ecc6e162383d00c3728ece`
Block 0:
- `prog_seed` - 0
- `nonce` - `0000000000000000`
- `header` - `0000000000000000000000000000000000000000000000000000000000000000`
- `mix_hash` - `faeb1be51075b03a4ff44b335067951ead07a3b078539ace76fd56fc410557a3`
- `final_hash` - `63155f732f2bf556967f906155b510c917e48e99685ead76ea83f4eca03ab12b`
Block 49:
- `prog_seed` - 0
- `nonce` - `0000000006ff2c47`
- `header` - `63155f732f2bf556967f906155b510c917e48e99685ead76ea83f4eca03ab12b`
- `mix_hash` - `c789c1180f890ec555ff42042913465481e8e6bc512cb981e1c1108dc3f2227d`
- `final_hash` - `9e7248f20914913a73d80a70174c331b1d34f260535ac3631d770e656b5dd922`
Block 50:
- `prog_seed` - 1
- `nonce` - `00000000076e482e`
- `header` - `9e7248f20914913a73d80a70174c331b1d34f260535ac3631d770e656b5dd922`
- `mix_hash` - `c7340542c2a06b3a7dc7222635f7cd402abf8b528ae971ddac6bbe2b0c7cb518`
- `final_hash` - `de37e1824c86d35d154cf65a88de6d9286aec4f7f10c3fc9f0fa1bcc2687188d`
Block 99:
- `prog_seed` - 1
- `nonce` - `000000003917afab`
- `header` - `de37e1824c86d35d154cf65a88de6d9286aec4f7f10c3fc9f0fa1bcc2687188d`
- `mix_hash` - `f5e60b2c5bfddd136167a30cbc3c8dbdbd15a512257dee7964e0bc6daa9f8ba7`
- `final_hash` - `ac7b55e801511b77e11d52e9599206101550144525b5679f2dab19386f23dcce`
Block 29,950:
- `prog_seed` - 599
- `nonce` - `005d409dbc23a62a`
- `header` - `ac7b55e801511b77e11d52e9599206101550144525b5679f2dab19386f23dcce`
- `mix_hash` - `07393d15805eb08ee6fc6cb3ad4ad1010533bd0ff92d6006850246829f18fd6e`
- `final_hash` - `e43d7e0bdc8a4a3f6e291a5ed790b9fa1a0948a2b9e33c844888690847de19f5`
Block 29,999:
- `prog_seed` - 599
- `nonce` - `005db5fa4c2a3d03`
- `header` - `e43d7e0bdc8a4a3f6e291a5ed790b9fa1a0948a2b9e33c844888690847de19f5`
- `mix_hash` - `7551bddf977491da2f6cfc1679299544b23483e8f8ee0931c4c16a796558a0b8`
- `final_hash` - `d34519f72c97cae8892c277776259db3320820cb5279a299d0ef1e155e5c6454`
Block 30,000:
- `prog_seed` - 600
- `nonce` - `005db8607994ff30`
- `header` - `d34519f72c97cae8892c277776259db3320820cb5279a299d0ef1e155e5c6454`
- `mix_hash` - `f1c2c7c32266af9635462e6ce1c98ebe4e7e3ecab7a38aaabfbf2e731e0fbff4`
- `final_hash` - `8b6ce5da0b06d18db7bd8492d9e5717f8b53e7e098d9fef7886d58a6e913ef64`
Block 30,049:
- `prog_seed` - 600
- `nonce` - `005e2e215a8ca2e7`
- `header` - `8b6ce5da0b06d18db7bd8492d9e5717f8b53e7e098d9fef7886d58a6e913ef64`
- `mix_hash` - `57fe6a9fbf920b4e91deeb66cb0efa971e08229d1a160330e08da54af0689add`
- `final_hash` - `c2c46173481b9ced61123d2e293b42ede5a1b323210eb2a684df0874ffe09047`
Block 30,050:
- `prog_seed` - 601
- `nonce` - `005e30899481055e`
- `header` - `c2c46173481b9ced61123d2e293b42ede5a1b323210eb2a684df0874ffe09047`
- `mix_hash` - `ba30c61cc5a2c74a5ecaf505965140a08f24a296d687e78720f0b48baf712f2d`
- `final_hash` - `ea42197eb2ba79c63cb5e655b8b1f612c5f08aae1a49ff236795a3516d87bc71`
Block 30,099:
- `prog_seed` - 601
- `nonce` - `005ea6aef136f88b`
- `header` - `ea42197eb2ba79c63cb5e655b8b1f612c5f08aae1a49ff236795a3516d87bc71`
- `mix_hash` - `cfd5e46048cd133d40f261fe8704e51d3f497fc14203ac6a9ef6a0841780b1cd`
- `final_hash` - `49e15ba4bf501ce8fe8876101c808e24c69a859be15de554bf85dbc095491bd6`
Block 59,950:
- `prog_seed` - 1,199
- `nonce` - `02ebe0503bd7b1da`
- `header` - `49e15ba4bf501ce8fe8876101c808e24c69a859be15de554bf85dbc095491bd6`
- `mix_hash` - `21511fbaa31fb9f5fc4998a754e97b3083a866f4de86fa7500a633346f56d773`
- `final_hash` - `f5c50ba5c0d6210ddb16250ec3efda178de857b2b1703d8d5403bd0f848e19cf`
Block 59,999:
- `prog_seed` - 1,199
- `nonce` - `02edb6275bd221e3`
- `header` - `f5c50ba5c0d6210ddb16250ec3efda178de857b2b1703d8d5403bd0f848e19cf`
- `mix_hash` - `653eda37d337e39d311d22be9bbd3458d3abee4e643bee4a7280a6d08106ef98`
- `final_hash` - `341562d10d4afb706ec2c8d5537cb0c810de02b4ebb0a0eea5ae335af6fb2e88`
Block 10,000,000:
- `prog_seed` - 200,000
- `nonce` - `005e30899481055e`
- `header` - `efda178de857b2b1703d8d5403bd0f848e19cff5c50ba5c0d6210ddb16250ec3`
- `mix_hash` - `b2403f56c426177856eaf0eedd707c86ae78a432b9169c3689a67058fcf2a848`
- `final_hash` - `206aee640c0fd21473d5cc3654d63c80442d9e2dfa676d2801d3ec1fbab38a6d`
Block 100,000,000:
- `prog_seed` - 2,000,000
- `nonce` - `02abe0589481055e`
- `header` - `49e15ba4bf501ce8fe88765403bd0f848e19cff5c50ba5c0d6210ddb16250ec3`
- `mix_hash` - `ac452084d6f4e6eacf4282ad58dbd4ce7ef2653fb5e6b5c877f56928c907432a`
- `final_hash` - `b879f84923e71b812ef5a42ece0b5b9366c31cab218f40afe65f8a2cae448a6f`
### 0.9.3
[Machine-readable data](https://github.com/ethereum/EIPs/blob/ad4e73f239d53d72a21cfd8fdc89dc81eb9d2688/assets/eip-1057/test-vectors-0.9.3.json)

View File

@ -3,53 +3,65 @@ layout: default
title: Home title: Home
--- ---
<h1 class="page-heading">EIPs <h1 class="page-heading">DCPs
<a href="https://discord.io/EthCatHerders"><img src="https://dcbadge.vercel.app/api/server/Nz6rtfJ8Cu?style=flat" alt="Discord channel for ECH eip-editer"></a> <a href="https://discord.io/EthCatHerders"><img src="https://dcbadge.vercel.app/api/server/Nz6rtfJ8Cu?style=flat" alt="Discord channel for ECH eip-editer"></a>
<a href="https://discord.gg/EVTQ9crVgQ"><img src="https://dcbadge.vercel.app/api/server/EVTQ9crVgQ?style=flat" alt="Discord channel for Eth R&D eip-editing"></a> <a href="https://discord.gg/EVTQ9crVgQ"><img src="https://dcbadge.vercel.app/api/server/EVTQ9crVgQ?style=flat" alt="Discord channel for Eth R&D eip-editing"></a>
<a href="https://discord.gg/mRzPXmmYEA"><img src="https://dcbadge.vercel.app/api/server/mRzPXmmYEA?style=flat" alt="Discord server for discussions about proposals that impact Ethereum wallets"></a> <a href="https://discord.gg/mRzPXmmYEA"><img src="https://dcbadge.vercel.app/api/server/mRzPXmmYEA?style=flat" alt="Discord server for discussions about proposals that impact Decentralized Foundation wallets"></a>
<a href="rss/all.xml"><img src="https://img.shields.io/badge/rss-Everything-red.svg" alt="RSS"></a> <a href="rss/all.xml"><img src="https://img.shields.io/badge/rss-Everything-red.svg" alt="RSS"></a>
<a href="rss/last-call.xml"><img src="https://img.shields.io/badge/rss-Last Calls-red.svg" alt="RSS"></a> <a href="rss/last-call.xml"><img src="https://img.shields.io/badge/rss-Last Calls-red.svg" alt="RSS"></a>
<a href="rss/nonerc.xml"><img src="https://img.shields.io/badge/rss-All except ERC-red.svg" alt="RSS"></a> <a href="rss/nonerc.xml"><img src="https://img.shields.io/badge/rss-All except ERC-red.svg" alt="RSS"></a>
<a href="https://eepurl.com/ikqNIP"><img src="https://img.shields.io/badge/-email%20alerts-red.svg" alt="RSS"></a> <a href="https://eepurl.com/ikqNIP"><img src="https://img.shields.io/badge/-email%20alerts-red.svg" alt="RSS"></a>
</h1> </h1>
<p>Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. Network upgrades are discussed separately in the <a target="_blank" href="https://github.com/ethereum/pm/">Ethereum Project Management</a> repository.</p> <p>Decentralized CLimate Foundation (DCIPs) describe standards for the Decentralized Climate platform, including core protocol specifications, client APIs, and contract standards. Network upgrades are discussed separately in the <a target="_blank" href="https://github.com/ethereum/pm/">Decentralized Climate Project Management</a> repository.</p>
<p>
</p>
<h2>Contributing</h2> <h2>Contributing</h2>
<p>First review <a href="EIPS/eip-1">EIP-1</a>. Then clone the repository and add your EIP to it. There is a <a href="https://github.com/ethereum/EIPs/blob/master/eip-template.md?plain=1">template EIP here</a>. Then submit a Pull Request to Ethereum's <a href="https://github.com/ethereum/EIPs">EIPs repository</a>.</p> <p>First review <a href="DCPS/eip-1">DCP-1</a>. Then clone the repository and add your DCP to it. There is a <a href="https://github.com/DECENTRALIZEDCLIMATE">template DCP here</a>. Then submit a Pull Request to Decentralized Foundation's <a href="https://github.com/DECENTRALIZEDCLIMATE/docs">DCPs repository</a>.</p>
<h2>EIP status terms</h2> <h2>DCP status terms</h2>
<ul> <ul>
<li><strong>Idea</strong> - An idea that is pre-draft. This is not tracked within the EIP Repository. <li><strong>Idea</strong> - An idea that is pre-draft. This is not tracked within the DCP Repository.
<li><strong>Draft</strong> - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.</li> <li><strong>Draft</strong> - The first formally tracked stage of an DCP in development. An DCP is merged by an DCP Editor into the DCP repository when properly formatted.</li>
<li><strong>Review</strong> - An EIP Author marks an EIP as ready for and requesting Peer Review.</li> <li><strong>Review</strong> - An DCP Author marks an DCP as ready for and requesting Peer Review.</li>
<li><strong>Last Call</strong> - This is the final review window for an EIP before moving to FINAL. An EIP editor will assign Last Call status and set a review end date (`last-call-deadline`), typically 14 days later. If this period results in necessary normative changes it will revert the EIP to Review.</li> <li><strong>Last Call</strong> - This is the final review window for an DCP before moving to FINAL. An DCP editor will assign Last Call status and set a review end date (`last-call-deadline`), typically 14 days later. If this period results in necessary normative changes it will revert the DCP to Review.</li>
<li><strong>Final</strong> - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.</li> <li><strong>Final</strong> - This DCP represents the final standard. A Final DCP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.</li>
<li><strong>Stagnant</strong> - Any EIP in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to Draft.</li> <li><strong>Stagnant</strong> - Any DCP in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. An DCP may be resurrected from this state by Authors or DCP Editors through moving it back to Draft.</li>
<li><strong>Withdrawn</strong> - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.</li> <li><strong>Withdrawn</strong> - The DCP Author(s) have withdrawn the proposed DCP. This state has finality and can no longer be resurrected using this DCP number. If the idea is pursued at later date it is considered a new proposal.</li>
<li><strong>Living</strong> - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.</li> <li><strong>Living</strong> - A special status for DCPs that are designed to be continually updated and not reach a state of finality. This includes most notably DCP-1.</li>
</ul> </ul>
<h2>EIP Types</h2> <h2>DCP Types</h2>
<p>EIPs are separated into a number of types, and each has its own list of EIPs.</p> <p>DCPs are separated into a number of types, and each has its own list of DCPs.</p>
<h3>Standard Track ({{site.pages|where:"type","Standards Track"|size}})</h3> <h3>Standard Track ({{site.pages|where:"type","Standards Track"|size}})</h3>
<p>Describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories.</p> <p>Describes any change that affects most or all Decentralized Foundation implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Decentralized Foundation. Furthermore Standard DCPs can be broken down into the following categories.</p>
<h4><a href="{{"core"|relative_url}}">Core</a> ({{site.pages|where:"type","Standards Track"|where:"category","Core"|size}})</h4> <h4><a href="{{"core"|relative_url}}">Core</a> ({{site.pages|where:"type","Standards Track"|where:"category","Core"|size}})</h4>
<p>Improvements requiring a consensus fork (e.g. <a href="./EIPS/eip-5">EIP-5</a>, <a href="./EIPS/eip-211">EIP-211</a>), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the PoA algorithm for testnets described in <a href="./EIPS/eip-225">EIP-225</a>).</p> <p>Improvements requiring a consensus fork (e.g. <a href="./DCPS/eip-5">DCP-5</a>, <a href="./DCPS/eip-211">DCP-211</a>), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the PoA algorithm for testnets described in <a href="./DCPS/eip-225">DCP-225</a>).</p>
<h4><a href="{{"networking"|relative_url}}">Networking</a> ({{site.pages|where:"type","Standards Track"|where:"category","Networking"|size}})</h4> <h4><a href="{{"networking"|relative_url}}">Networking</a> ({{site.pages|where:"type","Standards Track"|where:"category","Networking"|size}})</h4>
<p>Includes improvements around devp2p (<a href="./EIPS/eip-8">EIP-8</a>) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.</p> <p>Includes improvements around devp2p (<a href="./DCPS/eip-8">DCP-8</a>) and Light Decentralized Foundation Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.</p>
<h4><a href="{{"interface"|relative_url}}">Interface</a> ({{site.pages|where:"type","Standards Track"|where:"category","Interface"|size}})</h4> <h4><a href="{{"interface"|relative_url}}">Interface</a> ({{site.pages|where:"type","Standards Track"|where:"category","Interface"|size}})</h4>
<p>Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (<a href="./EIPS/eip-6">EIP-6</a>) and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.</p> <p>Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (<a href="./DCPS/eip-6">DCP-6</a>) and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an DCP is submitted to the DCPs repository.</p>
<h4><a href="{{"erc"|relative_url}}">ERC</a> ({{site.pages|where:"type","Standards Track"|where:"category","ERC"|size}})</h4> <h4><a href="{{"erc"|relative_url}}">ERC</a> ({{site.pages|where:"type","Standards Track"|where:"category","ERC"|size}})</h4>
<p>Application-level standards and conventions, including contract standards such as token standards (<a href="./EIPS/eip-20">EIP-20</a>), name registries (<a href="./EIPS/eip-137">EIP-137</a>), URI schemes (<a href="./EIPS/eip-681">EIP-681</a>), library/package formats (<a href="./EIPS/eip-190">EIP-190</a>), and account abstraction (<a href="./EIPS/eip-4337">EIP-4337</a>).</p> <p>Application-level standards and conventions, including contract standards such as token standards (<a href="./DCPS/eip-20">DCP-20</a>), name registries (<a href="./DCPS/eip-137">DCP-137</a>), URI schemes (<a href="./DCPS/eip-681">DCP-681</a>), library/package formats (<a href="./DCPS/eip-190">DCP-190</a>), and account abstraction (<a href="./DCPS/eip-4337">DCP-4337</a>).</p>
<h3><a href="{{"meta"|relative_url}}">Meta</a> ({{site.pages|where:"type","Meta"|size}})</h3> <h3><a href="{{"meta"|relative_url}}">Meta</a> ({{site.pages|where:"type","Meta"|size}})</h3>
<p>Describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.</p> <p>Describes a process surrounding Decentralized Foundation or proposes a change to (or an event in) a process. Process DCPs are like Standards Track DCPs but apply to areas other than the Decentralized Foundation protocol itself. They may propose an implementation, but not to Decentralized Foundation's codebase; they often require community consensus; unlike Informational DCPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Decentralized Foundation development. Any meta-DCP is also considered a Process DCP.</p>
<h3><a href="{{"informational"|relative_url}}">Informational</a> ({{site.pages|where:"type","Informational"|size}})</h3> <h3><a href="{{"informational"|relative_url}}">Informational</a> ({{site.pages|where:"type","Informational"|size}})</h3>
<p>Describes a Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs or follow their advice.</p> <p>Describes a Decentralized Foundation design issue, or provides general guidelines or information to the Decentralized Foundation community, but does not propose a new feature. Informational DCPs do not necessarily represent Decentralized Foundation community consensus or a recommendation, so users and implementers are free to ignore Informational DCPs or follow their advice.</p>