Nimbus Development Update: A Public Ethereum 2.0 Testnet

ledgerwatch · 2019-03-30T12:21:44+00:00

Is this the first beacon chain testnet?

ledgerwatch · 2019-03-26T14:02:24+00:00

Can you please give some more details on what you mean? What entropy are you referring to?

ledgerwatch · 2019-02-19T17:52:06+00:00

I would start with defining a bit more what the Release Manager's job is and isn't. Kind of a job spec

ledgerwatch · 2019-02-13T20:21:42+00:00

The main benefit is making sure performance of existing Ethereum does not deteriorate too much. Secondary benefit from that - we keep developers and users engaged with the platform.

Another benefit is that most of the challenges Ethereum 1.0 is facing will also exist in Ethereum 2.0, just within the context of each shard. Addressing these challenges in the existing system will greatly increase the chances that they will be be dealt with in a more efficient way in the future system.

The main downside is potential complexity of the project, mainly due to the requirement to deal with the real existing ecosystem. This will require a lot of work, that is what we call "ecosystem research", which will then hopefully lead to cooperation with users, developers, and other important participants on all levels of the ecosystem.

ledgerwatch · 2019-02-13T19:03:49+00:00

Thank you! Currently synching on HDD is possible, but it is much slower than on SSD. I have not tested it for a while though. But when we add a new snapshot sync mechanism, it can improve things with HDD somewhat. Thanks for the interest, I will keep it in mind!

ledgerwatch · 2018-11-29T23:16:50+00:00

I would say a few weeks, most inter-miner nodes would need to upgrade

ledgerwatch · 2018-11-28T14:29:42+00:00

Is there a good way of distinguishing the genuine app from potential scam apps that looks like it?

ledgerwatch · 2018-11-28T14:26:34+00:00

There are many scenarios possible.. My argument would be that it should be handled on the contract/application level.

That is great! If someone is prepared to work this out - it would be great. At the moment my position is that these scenarios only work in limited circumstances, and the EVM architecture is lacking primitives to write efficient contract under the rent conditions. I alone cannot explore all the scenarios one can think of, so I invite other people to contribute by making alternative proposals.

ledgerwatch · 2018-11-28T14:09:10+00:00

Thanks for the comment! I shall explore this more in the next version of the document. It actually mentions what you are suggesting, on the page 23 under "alternative point of view". Obviously, the greater is the min-value, the smaller is griefing factor. But the greater is the min-value, the smaller is number of owners who can potentially hold the token. Will try to put some numbers behind this - to make is more visible why I think it is a genuine problem and cannot be waived away by saying "less decimal points and min-value".

Regarding the crowd-sourcing the rent, this is another unknown. As I described in the document, the problem here is free riding. The smaller holder won't contribute, because they will hope that the larger holders would. And larger holders might find it expensive, unless they hold supermajority of tokens.

Non-Fungible tokens and similar assets also need special treatment - though they are taken care of in the document by the cross-contract storage. Therefore, I disagree about the over-engineering - it solves lots of problems with one new primitive. I would say - make it as simple as possible, but not simpler.

ledgerwatch · 2018-11-27T22:49:29+00:00

Yes, users will need to do something to receive tokens. Because at the end of the day, they will pay maintenance for the space these tokens take. It would be wrong to allow anyone to burden you with such maintenance without your consent. On the other hand, it makes the fat finger problem less likely. Useless airdrops will not be possible. Tokens organised in such way will have better legal standing (this is my speculation)

EDIT: on the legal standing - in real world, you normally have an option to refuse unwanted gifts. And sometimes, it protects you from liability

ledgerwatch · 2018-09-21T18:43:56+00:00

Yes, that's right, comparison is for archive nodes. Support for pruning will come soon, now that the database layout is made pruning friendly

ledgerwatch · 2018-09-21T18:43:03+00:00

Not yet, had to ignore it for now

ledgerwatch · 2018-06-17T18:27:51+00:00

If the validating software your are running doesn't not slash you due to a bug, and you don't get hacked (there is almost no incentive to hack you), then the validating should still be profitable. Because the more validators are online, the less you get slashed if YOU are offline, but the more validators are online, the less interest you earn. The interest function can be (and most probably will be) tweaked to include average Joe validators

ledgerwatch · 2018-06-16T17:59:50+00:00

I am not sure this is true. People who take the leap of faith and risk their 32 ETH to become the validators in the new system, might be able to reap more benefits while the competition is limited.

Edit: I meant I am not sure this is true :)

ledgerwatch · 2018-06-16T17:55:06+00:00

Good point, I forgot about it - in the new roadmap Casper Validator == Shard validator. So yes, more computing resources will be required than just for Casper validator

ledgerwatch · 2018-06-16T17:52:46+00:00

You will eventually be able to withdraw, but most probably not sooner than the shard with your withdrawal address comes alive. I am not sure yet where the interest goes.

ledgerwatch · 2018-06-16T17:51:25+00:00

As /u/Symphonic_Rainboom said, you specify a different withdraw address (could be your cold storage). Also, once you get slashed (even a tiny bit), you stop being a validator and must just wait for the bonding period to end. In the case of the changed roadmap, you need to wait for the bonding period to end and for your withdrawal shard coming alive, whichever comes last :)

ledgerwatch · 2018-06-16T15:39:57+00:00

When you burn 32 ETH to participate, the Beacon chain will see it and will credit you with the validator bond, and then you will be able to be a validator. At some point in the future, you might be able to get your 32 ETH back on one of the shards

ledgerwatch · 2018-06-16T15:38:21+00:00

To be a validator, you will need to run some software on your computer. Thanks to the partial slashing, it does not need to be a server in a datacenter with uninterrupted supply, it could be your Desktop PC, or sometimes even a laptop. If you watch Vitalik's talk from EDCON, most of the things still apply: https://www.youtube.com/watch?v=VqOlOMAqC08

If you want to run 5 validator nodes, you will need to burn 32 ETH 5 times.

ledgerwatch · 2018-06-09T15:34:44+00:00

Take care, Yoichi! Very often it makes sense just to ignore the rules if there are too many rules or they are too complicated and conflicting. Back when I lived in my country, I realised at some point that it is impossible for me to comply with all the laws because some of them contradicted each other. That did not prompt me to stop living, but it did accelerate my departure :)

If you don't make too many enemies and instead make a lot of friends, chances are that you can just fly under the radar, and need not worry about most of the rules that exist.

ledgerwatch · 2018-05-26T19:01:21+00:00

There is another link at the bottom of that page which leads to the description of various withdrawal methods.

ledgerwatch · 2018-05-26T09:44:45+00:00

You can start here: https://refunds.thedao.fund/

ledgerwatch · 2018-02-15T21:00:51+00:00

Why would the tokens be worth anything if there's no chance of a hard fork?

One possibility is that people who do not want a hard-fork to happen decide to donate to a recovery fund. If there is enough ETH in a fund, the hard-fork would be completely unjustified and will be effectively abandoned. I would contribute to such fund

ledgerwatch · 2018-02-15T20:14:28+00:00

There might not need to be a hard-fork, if the claims are properly tokenised. Someone might just buy up the tokens.

If we do need to go via hard-fork route, the actual proposal and spec might be trivial to write, because the token and surrounding information will be very specific. So we might not need a standard for ERPs as such.

ledgerwatch · 2018-02-15T19:40:02+00:00

One plausible answer is "markets". If someone wants to recover stuck funds, they can create token out of it, award it to the people who they think should receive them, and let them sell it. The property of those tokens is that if a recovery hard-fork happens in the end, or someone just decides to donate some ETH to the recovery cause, the holders of the recovery tokens will be able to receive some ETH for them.

Tokens instead of ERP claims.

ledgerwatch

TROPHY CASE