sourcify
sourcify copied to clipboard
ethereum
SourceVerify as DappNode app
In the spirit of decentralisation it would be great if more people could run the source-verifier. By providing it as a @dappnode app the barrier to do this can be lowered dramatically. There are already DappNode packages for IPFS/Swarm clients for multiple ETH networks that we can use as dependencies. Also dappnode packages are in the end glorified docker containers and we use docker-containers for our source-verify instances already this should be a very low-hanging fruit.
As a first step we should provide it so users can install it like this:
And as a second step we should provide it via the dappstore:
If access to a DappNode to work on this issue is a blocker - please let me know.
Reviewing this and how it works, it should be viable to implement. Question is should we publish all the services in there so users can run (server,monitor,ui,ipfs publisher etc) or just the ui?
UI would connect to our server so it would be a centralized option, but adding also server and monitor would make the whole process decentralized.
So I would propose a test package with just UI and then adding other services (monitor, server) later on. You thought on this? @ligi
I have a little bit of experience developing a dAppNode docker image, plus I have a dAppNode. Happy to help where I can.
Any help is definitely welcomed.
It would be great if you could join our weekly call: https://gitter.im/ethereum/source-verify or we can jump on a call one day to discuss this if you have time. :)
As just discussed in the call - this would be how the MVP for this can look like:
- (0) on the first run it would download the current state from our IPNS url (or maybe make this a parameter and default to our IPNS) - calling it source repo for now
- (1) verify all contracts we got in step (0)
- (2) on successful recompilation it will move this content to a folder that is accessible via http://sourcify.dappnode/repo (that follows our directory structure)
- (3) wait for some time (maybe make this waiting time a parameter)
- (4) download the current state from the source repository and calculate a diff
- (5) recompile all contracts in the diff and move them like in (2)
- (6) pin our repo to IPFS (ideally this is then the same hash that is resolved from the source repo so all people running sourcify on the dappnode help distributing/seeding the content)
- (7) GOTO (3) yes I know GOTO is evil - just for the sake of simplicity here
Open question:
- what would be a good action to take if a recompilation fails (in the current MVP this would just lead to the contract not being included in our local repo)
- for after the MVP: what can be a good way to publish (e.g. a signature of) our local repository?
- what would be a good timing for (3)
cc @eduadiez @tjayrush
Note that seeding the content is already very helpful even if it is not the same root hash. The entry point does not have to be the sourcify repo - it can (and maybe should) be the on-chain metadata hash. So seeding metadata and sources is helpful even if they are not in the same directory structure.
I think we have to create an exclusion list for contracts that fail to compile, otherwise we recompile on each sync.
Couldn't steps 0-3 be removed?
- (4) download the current state from the source repository and calculate a diff (initially, diff will be everything)
- (5) recompile all contracts in the diff and move them like in (2)
- (6) pin our repo to IPFS (ideally this is then the same hash that is resolved from the source repo so all people running sourcify on the dappnode help distributing/seeding the content)
- (7) GOTO (4) yes I know GOTO is evil - just for the sake of simplicity here
Otherwise this looks good!
@chriseth good point with the simplification!
So updating the proposal:
Inputs: source repo: a URL with a sourcify style repository - will default to our IPNS address in the beginning - but should be configurable
Process:
- (0) download the current state from the source and calculate a diff to our local repo (initially the diff is equal to the source repo)
- (1) recompile all contracts in the diff and when they verify move them to the local repo
- (2) pin our local repo to IPFS (ideally this is then the same hash that is resolved from the source repo so all people running sourcify on the dappnode help distributing/seeding the content)
- (3) sleep a defined amount of time
- (4) goto (0)
Sourcify User Interface: http://my.dappnode/#/installer/%2Fipfs%2FQmVgkwLjn4zdctX1btHMY92AhXfzVVfDckPcyZ5wMXYyK1
Sourcify Server: http://my.dappnode/#/installer/%2Fipfs%2FQmXkaRGTstttT1qxBiAEsXVgoWHYmyUmarAvEusA2R5qrT
Sourcify Contract Repository: http://my.dappnode/#/installer/%2Fipfs%2FQmSPXGyRnk5aK4QNi63omHHnkPXAoF9C3ZHEVNBzzESLWT
Updated DNPs: Sourcify User Interface: http://my.dappnode/#/installer/%2Fipfs%2FQmNp7c1DaTJ1PYP79XFBgY8Td33XRiCV4H6iGPkK12HN2F
Sourcify Server: http://my.dappnode/#/installer/%2Fipfs%2FQmfNGQ7K7cExuPzVCCXdJhtC2Ym57UwGht8XStyArDZ1XP
Sourcify Contract Repository: http://my.dappnode/#/installer/%2Fipfs%2FQmPwMYWaFLhsLmHaGnWAgwxoSkdcKgQxCmZAtJzihZkaHX
Single package version: /ipfs/QmUG9QaxARUtiH997K2vyrEPMX599aYfYLoU4TauDQFFsw http://my.dappnode/#/installer/%2Fipfs%2FQmUG9QaxARUtiH997K2vyrEPMX599aYfYLoU4TauDQFFsw
Hey, is anyone still working on this? Would love to have a look at this package, but it seems to be forgotten by ipfs...
@TripleSpeeder for me they are still resolving - would be great if someone could pick this up again
I will pin it on another machine - maybe this helps you to get it - otherwise I send it to you on some other channel
EDIT: just pinned them on a different machine:
LMK if you still have problems accessing it.
Just note: In a recent call (also happy if you join one of our monday calls) we agreed to not continue the efforts of having a sourcify UI as dappnode package - just what I outlined in the original issue.