Limit who can execute the smart contract

[ebaizel]

Limit who can execute the smart contract

[OR13]

I discussed this with @csuwildcat at IIW.

Seems like a post "mvp" feature to me. I'd like to see working CRUD operations on DIDs with tests before restricting who can anchor to ethereum.

Whatever amount is chosen for the staking minimum will become a barrier to entry for sidetree node operators, if the value is too high, it will exclude too many potential adopters, if its too low, it will be unnecessary complexity.

Why is gas cost not enough of a DoS mitigation strategy here?

How much USD does an attacker need to spend to make the network inoperable?

Consider also that the IPFS data will by default make this more like a PoA network (we must trust the IPFS node operators to make hashes available, there is no decentralized storage incentive here yet), we might consider formalizing this PoA assumption for the first version, in which case I would expect a whitelist of nodes who are allowed to anchor to the contract, which would also be simpler than staking.

[csuwildcat]

Good comments by Orie.

I'd really encourage folks here from the Ethereum community to focus on deterministic, algo-oriented means of DDoS mitigation. I'm not quite as familiar with Ethereum, but I'd look to include elements like PoW high watermarks, gas requirements, and other facets first, then, if need be, include other variables.

[ebaizel]

i spoke to Orie about this at IIW as well, and i completely agree this is a post MVP feature.

the issue that i am referencing here is different (i believe) than the DDOS issue. this is an authorization issue concerning who is allowed to update the smart contract. since the contract will live on the public ethereum network, it will be visible and accessible to anyone, meaning anyone could call the function that adds data to the contract. all the validation logic will live in the side tree node, so the contract simply exposes a function that lets you add an anchor hash to its state.

typically, smart contracts will define one or more actors (public addresses) who have permission to execute certain functions, which would prevent just anyone from updating its state. for the mvp, we could restrict access to one address which is known by the sidenode. post mvp we can think about how to open this up to more actors.

happy to table this issue for now. do we use a tag to indicate an issue that shouldn't be worked on at the moment? like backlog or not yet

[csuwildcat]

@ebaizel I think the difference with approach here is the suggestion (if possible) that you allow anyone to write to the contract, so long as you can tie writes to a deterministic algo (something that links gas, batch size, and write frequency?) that mitigates malicious load on the contract. I simply don't know what global/contract vars are available to incorporate in such an algorithm, because I'm not as familiar with Ethereum.