search

ethereum-funding / blockrewardsfunding

Project Management is happening in this repo, see the Issues! This is a fork of ethereum/eips.
18 stars 3 forks source link

What are some Technical implementation restrictions on the dispursement mechanism? #44

Open glauseWilde opened 5 years ago

glauseWilde commented 5 years ago

Been trying to understand the technical limitations on any proposed systems. I want to see if my proposed version is also technically feasible. I found the thread below really helpful for anyone looking at the same things. Particularly the points about state size being effected.

If the faucet has multiple endpoints (1/3 to 0x34.. 1/3 to 0x4h.. etc..) How could this be implemented in a way that doesn't have the problems GregTheGreek mentions. And if the metaDao were able to change these numbers what then?

Functional Requirements I would be looking for:

I could see a few ways this might be done; one way to do this would be to split the faucet into x shares and then decide how many shares each address gets (out of 100 for example); Two, split it into hard eth values with a check on the limit.

I understand that sending to one address is the easiest. My goal is that the metaDao members not have custodial control of the funds directly. If they only control where the faucet deposits then there is no accumulation of funds that they would need to address. How is this possibly implemented from a technical perspective?

@owocki To add to Lane's comment. This version would mean its a fixed number to a fixed address. So everyone would need to agree with it!

If you want it to be dynamic, so that anyone could chose their how much and where to send, it gets quite complicated and requires a more extensive mods. Which I eluded to in previous discussions

Originally posted by @GregTheGreek in https://github.com/ethereum-funding/blockrewardsfunding/issues/6#issuecomment-472232475

owocki commented 5 years ago

i was thikning we'd adopt the MolochDAO design principle of "keep the attack surface as low as possible" Funds would go to an M of N multi-sig and the multi-sig holders would have to be completely transparent about how they decide where the funds go.

GregTheGreek commented 5 years ago

Main point to answer the technical question. Dynamic addresses require a consensus change, doing so requires a way for the mining node to broadcast his chosen deposit address as well as how much of the reward.

GregTheGreek commented 5 years ago

Thats definitely one way to do it, but I would be interested in hearing about latency issues. Because that would require the nodes to query this registry when applying rewards after a block has been accepted. That also alters the how the consensus works...

jpitts commented 5 years ago

^^ Ah, sorry, I think that this was in response to something which I had deleted. (I was proposing that a new kind of validation node be used instead of relying on miners). I need to think it through a lot more and should stay on subject.

glauseWilde commented 5 years ago

I think all of these have been on point jpitts. I don't yet see a way around the operational complexity of changing who gets what part of the faucet. If there was a delay as it propagates that would be fine as long as finality is reached eventually.

i was thikning we'd adopt the MolochDAO design principle of "keep the attack surface as low as possible" Funds would go to an M of N multi-sig and the multi-sig holders would have to be completely transparent about how they decide where the funds go.

I can see this as being the simplest way to collect the funds, but I really hope we can find a different way to distribute the faucet directly to subgroups. Part of what undid the ECF was having the keys to a pile of money.

These two lines of thinking are very different to me. 1) We have x funds. How much do we give to whom to make the biggest impact?

2) This group is doing well at allocating funds, we should increase their faucet. This group is not doing well lets decrease it temporarily until they do better. This group failed to deliver and it is time to cut them off.

The time and governance overhead of 1 is primarily the struggle I see the EF is having with grants. The answer to 2 is much more straightforward.

Also, not having a pile of money keeps the honey pot low relating to

keep the attack surface as low as possible.

That is assuming there is a way to code this that doesn't increase the attack vectors even more.

glauseWilde commented 5 years ago

Maybe I am over thinking it. Perhaps a faucet contract could handle all of these. @lrettig https://github.com/ethereum-funding/blockrewardsfunding/issues/25#issuecomment-474079723

Able to send to multiple addresses (multiple funding groups) Able to add/remove addresses during the implementation phase (via the metaDao motions) Able to change the allotment to each address (Increase or decrease funding as trust is built or funding goals met)

I would add also add