forked from DecentralizedClimateFoundation/DCIPs
Se arreglaron los DCIPs
This commit is contained in:
Team1
parent
743d90e423
commit
f07399d149
|
|
@ -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
|
||||
---
|
||||
|
||||
|
||||
|
|
@ -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
|
||||
---
|
||||
|
||||
|
||||
|
||||
|
||||
**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.
|
||||
|
||||
|
||||
|
||||
## :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
|
||||
|
||||
|
|
@ -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
|
||||
---
|
||||
|
|
@ -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**
|
||||
|
||||
|
||||
______________________
|
||||
Luis Alberto Saavedra Nieto.
|
||||
|
||||
|
||||
______________________
|
||||
David E. Pérez Negron R.
|
||||
|
||||
|
||||
______________________
|
||||
Omar Octavio Huerta Valdez.
|
||||
|
||||
|
||||
______________________
|
||||
Christian Sandoval.
|
||||
|
||||
|
||||
______________________
|
||||
Alfonso Nuñez.
|
||||
|
||||
|
||||
______________________
|
||||
Marco Blanke.
|
||||
|
||||
|
||||
402
EIPS/eip-1.md
402
EIPS/eip-1.md
|
|
@ -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:
|
||||
|
||||
|
||||
|
||||
**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 <address@dom.ain>
|
||||
|
||||
or
|
||||
|
||||
> Random J. User (@username)
|
||||
|
||||
or
|
||||
|
||||
> Random J. User (@username) <address@dom.ain>
|
||||
|
||||
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).
|
||||
|
|
@ -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
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
121
EIPS/eip-5.md
121
EIPS/eip-5.md
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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.
|
||||
388
EIPS/eip-8.md
388
EIPS/eip-8.md
|
|
@ -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).
|
||||
14
README.md
14
README.md
|
|
@ -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 [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.
|
||||
- [Networking EIPs](https://eips.ethereum.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.
|
||||
- [ERCs](https://eips.ethereum.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.
|
||||
- [Informational EIPs](https://eips.ethereum.org/informational) are non-standard improvements that do not require any form of consensus.
|
||||
- [Core EIPs](https://dcips.decentralizedclimate.org/core) are improvements to the Ethereum consensus protocol.
|
||||
- [Networking EIPs](https://dcips.decentralizedclimate.org/networking) specify the peer-to-peer networking layer of Ethereum.
|
||||
- [Interface EIPs](https://dcips.decentralizedclimate.org/interface) standardize interfaces to Ethereum, which determine how users and applications interact with the blockchain.
|
||||
- [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://dcips.decentralizedclimate.org/meta) are miscellaneous improvements that nonetheless require some sort 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.**
|
||||
|
||||
|
|
|
|||
|
|
@ -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**
|
||||
|
||||
|
||||
______________________
|
||||
Luis Alberto Saavedra Nieto.
|
||||
|
||||
|
||||
______________________
|
||||
David E. Pérez Negron R.
|
||||
|
||||
|
||||
______________________
|
||||
Omar Octavio Huerta Valdez.
|
||||
|
||||
|
||||
______________________
|
||||
Christian Sandoval.
|
||||
|
||||
|
||||
______________________
|
||||
Alfonso Nuñez.
|
||||
|
||||
|
||||
______________________
|
||||
Marco Blanke.
|
||||
|
||||
|
||||
|
|
@ -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"
|
||||
}
|
||||
]
|
||||
|
|
@ -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"
|
||||
}
|
||||
]
|
||||
|
||||
|
|
@ -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)
|
||||
56
index.html
56
index.html
|
|
@ -3,53 +3,65 @@ layout: default
|
|||
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.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/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="https://eepurl.com/ikqNIP"><img src="https://img.shields.io/badge/-email%20alerts-red.svg" alt="RSS"></a>
|
||||
</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>
|
||||
<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>
|
||||
<li><strong>Idea</strong> - An idea that is pre-draft. This is not tracked within the EIP 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>Review</strong> - An EIP Author marks an EIP 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>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>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>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>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>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 DCP in development. An DCP is merged by an DCP Editor into the DCP repository when properly formatted.</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 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 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 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 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 DCPs that are designed to be continually updated and not reach a state of finality. This includes most notably DCP-1.</li>
|
||||
</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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue