-
Notifications
You must be signed in to change notification settings - Fork 28
Anchoring elements are not stored in the anchor contract #196
Comments
@Therecanbeonlyone1969 thanks for raising this. Can we clarify what we mean by 3rd party, I assume given the contract changes, the desire is to be able to write smart contracts that interact with the anchoring more directly? The current model is definitely designed with the intention of not inviting contracts to do anything, and the reason for this is to keep the ethereum anchoring as close to the bitcoin anchoring as possible. Another thing to note, is that the side of anchorFileURI is now larger than bytes32... we will need to adjust for that as well... cc @gjgd |
@OR13 3rd party refers to anyone (non-contract) ... we could add a check to ensure that msg.sender is not a contract -- there is an open-zeppelin contract for that ... we could just extract the function. That is a good point.
and in the anchoringHash function we can add at the beginning before we increase the transaction number the following check That would solve the problem that a contract can call the function ... except in the case that the contract is called in another contract constructor. Thoughts? |
oh and the anchor file URI is strong so we can make that longer @OR13 |
We went with the event based approach instead of storing in the anchor contract because storing values is significantly more expensive than to emit an event in terms of gas. We use web3's getPastEvents to get the data emitted by events. Also, can you clarify your distincting between anchorHash and anchorURI ? |
I understand the approach to use log storage to avoid paying for gas. With 1.X that approach will no longer work since the logs will be flushed after a certain length of time in order to reduce the data that has to be stored by a client. Hence, to future proof the design, I would highly recommend to pay for the gas -- not that much anyway. The URI is the IPFS hash such that I can get to the leafs and recompute the roothash. |
Isn't that the anchorHash? Why do you have two hashes? |
I was under the impression that we have both the IPFS hash and the Merkle Trie Roothash at our disposal ... this would provide two anchor points. |
We just write the anchorFileHash to the smart contract, which itself contain the reference to the merkle tree hash and the batch file hash (containing operation data). This 2 file structure allows us to have just one anchor hash. See this transaction for example: https://element-did.com/server/transactions/0xabfdcf79494c3a36072ecb641cc049e27cf335be4218771852bb1c2564e6456b
|
@Therecanbeonlyone1969 The Merkle Trie stuff was removed from the latest spec: https://identity.foundation/sidetree/spec/ The general design considerations for the previous contract were the following:
I think in the next version of the contract, we want to consider:
|
@OR13 ... ok. need to read the latest spec. totally understand the design criteria for v1 of the contract. I think we need to account for in the new design:
Lastly, I am not so sure that we should not make becoming an operator for others more expensive -- we could have a simpler version of the contract that non-operator nodes who want to run their own thing can use but that is then at their own risk.My 2 wei. |
I left a comment here: #197 (comment) If we can, I'd prefer to adapt something general purpose and proven to this problem, rather than innovate here. |
The current SimpleSidetreeAnchor.sol does not store the anchoring elements in the smart contract such that they could be verified by a 3rd party. Suggest to amend the contract the following way:
`pragma solidity 0.5.0;
contract SimpleSidetreeAnchor {
struct Anchor {
address operator;
bytes32 anchorhash;
string anchorURI;
}
} else {
return (anchor[transactionNumber].operator, anchor[transactionNumber].anchorhash, anchor[transactionNumber].anchorURI);
}
}`
The text was updated successfully, but these errors were encountered: