Store encrypted submissions in a cheaper location

[theref]

Research is required here.

https://ethereum.org/en/developers/docs/storage/ https://www.techtarget.com/searchstorage/tip/Comparing-4-decentralized-data-storage-offerings

The L1 or L2 Manager contract can then store only election metadata, which would include the IPFS pin (or equivalent).

[theref]

IPFS is the industry standard and largest network, so let's go with that. Here is a good overview of how IPFS, Filecoin, and some other projects fit toegether. In summary:

Filecoin and IPFS are complementary protocols for storing and sharing data in the distributed web. IPFS is a content-addressed data system that does not have built-in mechanisms to incentivize the storage of data for other people. On the other hand, Filecoin adds an incentive layer to content-addressed data. Providers submit proofs of storage to the network over time, and payments, penalties, and block rewards are all enforced by the decentralized protocol.

There are several projects to simplify this process:

• https://estuary.tech/
• https://github.com/orbitdb/orbit-db
• https://web3.storage/
• https://www.pinata.cloud/

The question becomes which of these suits our needs best

[theref]

https://ardrive.io/how-much-does-it-cost-to-store-on-arweave/ https://ar-fees.arweave.dev/

[theref]

The data in this vote transaction is about 6.2 KB (https://www.javainuse.com/bytesize) Cost at time of writing on arweave would be less then $0.01

[theref]

ok, this lot are doing infura like services for arweave and they have a python sdk https://web3infura.io/docs/arseeding/sdk/arseeding-py

so we can do all of that in the secure backend (no security risk because at this point the submission should already be encrypted in the browser)

[theref]

https://github.com/oceanprotocol/pybundlr/tree/main

[theref]

Bundlr/arweave allow you to tag txs. Those tags can then be used for qraphql queries. So we can just tag all submissions with the election id. Possibly means that storage location is no longer required. By definition everything in on arweave and they'll be tagged with the relevant id.

This possibly opens up spam though, anyone could post to arweave with the relevant tag. This doesn't matter in terms of voting results (normal decryption & zk validation still applies). But all of those submissions would need to be decrypted and checked which could be expensive.

Maybe the graphql query filters on the tx sender? If a user wants to submit/store a vote themselves, they need to write to the scroll contract (cost). For user added storage locations, maybe this also some address matching happening? Obviously this reveals some info about the user...it's up to them to obfuscate that.

[theref]

Questions have been answered. This is now replaced by actionable https://github.com/electora-vote/electora-app/issues/44 and https://github.com/electora-vote/electora-app/issues/45