Comments (20)
Are we including an ice age delay (and an accompanying mining reward reduction) in the Constantinople hard fork? My understanding is that blocktimes will start being impacted in early 2019
from pm.
Better 2018-07-13 if we care about being ISO standard and non-bizarre-US-date-format friendly.
Just sayin' :-).
[Or in full, 2018-07-13T14:00Z, but that's a bit fussy]
from pm.
I have a question worth discussing at the next meeting. EIP 1011 (Hybrid Casper) seems not to happen for reasons that were mentioned in Ethereum research circles. I'm not strictly following it but what I want to figure out is, if we do not work on a hybrid Casper as discussed in EIP 1011 now, there won't be any progress on a joint testnet anymore. I don't see sharding and Casper-as-a-Shard to be ready anytime soon. So, actual question:
- Is there still the interest among client developers to have a joint testnet, a Ropsten-successor if you want to put it like that?
- If yes, and I assume most of us are interested in some effort like this, how could it look like if not like the hybrid Casper proposal?
I want to understand if there is anything we could start working on towards a joint testnet that could be useful for any future main net usage.
from pm.
In order to get the conversation started I created this proposed timeline:
Proposed Constantinople Timeline
Finalize EIPs that are being implemented: July 13th
Client implementation: July 16th - August 13th
Testing: August 13th - September 10th
Testnet: September 10th - October 1st
Launch: October 8th
This is not final and there will likely be changes. I am soliciting feedback from client devs and testers who will be working on this.
from pm.
Tag @AlexeyAkhunov who brought up something similar at ECDC - what smaller steps can/should we take in the meantime while waiting for casper+sharding? (can we just call it "shasper" now?)
from pm.
Some pre-notes on testing / timeline
I would agree with @AlexeyAkhunov that there should be a stronger emphasis on the tests in the timeline. Are these more or less ready for Constantinople (@winsvega)? I would say that the client dev 4-weeks period should only start once tests are 90%+ finalized.
I have doubts that this should already rely on the retesteth tool, since this still has a Prototype and WIP
note. Think this is too early and clients already have their custom test setup in place. Seems to me that this would give unnecessary additional time pressure for implementation. Does this add any functional benefit? Or is this just a unified interface?
State of EthereumJS VM
Can't join todays call, some estimate of the EthereumJS
VM state:
We are more-or-less fully passing the current over-time updated Byzantium
tests and have done some initial work on Constantinople
. My estimate would be that we could have an implementation ready within 2-3 month - also depending on some external circumstances.
Role of EthereumJS VM:
The EthereumJS
VM is not currently building the basis of a consensus-critical client, but is relevant for developers to test for Constantinople compatibility in tools like Remix
or Truffle/Ganache
.
from pm.
I also suggest that instead of trying to "approve" the list of EIPs for Constantinople hard fork, we instead work on the individual candidate EIPs and release (hard fork) them when they are ready. Current process of bundling changes in the big releases is based on the assumption that doing hard forks is hard, but why? Because we don't cleanly separate the old and the new network - this could be fixed by the practice of changing network Id in each fork. Because we start with underspecified EIPs and figure out the details in a rush just before the fork - this could be fixed by having EIP maturing process include mandatory rough reference implementation (enough to produce conformance tests), conformance tests, and only then full spec. If some more work is done to figure out underspecified and unimplementable things before the final spec, implementation of EIPs in all clients could be a much more straightforward process. If an EIP has a lot of good preparatory work behind it, it should be given some priority in consideration for the hard fork.
from pm.
I'm very excited to announce here that we at PegaSys are planning on releasing our open source mainnet-compatible Ethereum client, Pantheon, at DevCon 4!
Our Java client will meet the requirements of a well-behaved peer: able to synchronize the entire chain through all of the hard forks, mine blocks, and propagate pending transactions. The client will also be developer-friendly, supporting common dApp development (e.g. Truffle and web3) and deployment use cases. This means that the client will support the JSON-RPC APIs used by popular clients (e.g. eth, net, debug, admin, etc.), but not technologies such as Whisper or Swarm. We are focusing on functionality, robustness, and modularity.
We will be providing more information in the coming weeks, and we will also continue to increase our community involvement.
from pm.
typo in the date, should probably be 07/13/18 unless the EF is also secretly working on a time machine.
from pm.
Thanks :) updated
from pm.
@5chdn @lrettig Adding to agenda.
from pm.
I suggest changing network Id in Constantinopole (or, alternatively, the format of the handshake message to make it backwards-incompatible). This would allow removing some of the DAO hard fork kludge code from the clients by more cleanly separating from Ethereum Classic network. This change does not strictly require a hard fork, but it does require coordination from all the client impementations. I also see if as a stepping stone for the migration to the new peer discovery protocol and other improvements in p2p
from pm.
Regarding Constantinople timeline: I suggest that we demand that each client implements retesteth RPC methods. This would enable us creating a suite of conformance tests for every EIP in the list, and the time line would include steps like:
Finalize EIPs that are being implemented: July 13th
All clients have retesteth interface: Aug 13th
Each EIP has at least 1 reference implementation: Sep 13th
Conformance tests are ready for every EIP: Oct 13th
Specification is finalised for every EIP: Oct 27th
Client implementations and testing: Nov 27th
Testnet: Dec 13th
Launch: Jan 27th
from pm.
Please list the EIPs which are confirmed for the Constantinople hf.
So far I saw that only bitwise shift is approved. What else?
from pm.
@winsvega I think that's the optimal outcome of this call.
from pm.
The question around ewasm came up ad-hoc, but here is the link to the "precompiles in ewasm" discussion: ewasm/design#104
from pm.
I'm strongly in favor of including EIP 1087 in Constantinople. Several contracts with high usage on ETH (e.g. Augur, Bancor, etc) have inflated gas costs today because they repeatedly edit the same storage values. Implementing EIP 1087 will make these types of contract calls more feasible on the blockchain
from pm.
What happened to https://eips.ethereum.org/EIPS/eip-999 Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4? At least can we get EIP 999 as an option so users can decide whether to activate it or not in the next hard fork?
from pm.
Brilliant news, @shahankhatch! Many congratulations. This has been quite the labor of love for you and PegaSys. I am sure that Pantheon will be carrying a major chunk of the ETH mainnet soon enough. I hope to be there in Prague to witness "the birth" :-)
https://twitter.com/BobSummerwill/status/1017900957034614784
from pm.
Closing in favor of #51
from pm.
Related Issues (20)
- Execution Layer P2P Breakout #3 HOT 2
- Dencun Interop Testing Call #31 HOT 3
- Consensus-layer Call 118 HOT 2
- EOF Implementers Call #23 HOT 1
- Verkle Implementers Call #6 HOT 5
- Execution Layer Meeting 171 HOT 8
- Dencun Interop Testing Call #32 HOT 2
- EOF Implementers Call #24 HOT 2
- Consensus-layer Call 119 HOT 1
- Add extra line
- Execution Layer Meeting 172 HOT 3
- Dencun Interop Testing Call #33 HOT 2
- Verkle Implementers Call #7 HOT 2
- Execution Layer P2P Breakout #5
- RollCall #0 - Layer 2 protocol & EVM standardization call #0 HOT 15
- EOF Implementers Call #25
- Execution Layer Meeting 173 HOT 6
- Dencun Interop Testing Call #34 HOT 4
- EOF Implementers Call #27 HOT 2
- Consensus-layer Call 120 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pm.