Open jfinkhaeuser opened 5 years ago
This issue is left dangling here with very little further explanation. We've been discussing it in the context of https://github.com/Joystream/joystream/pull/45, however, so it should be specced out better.
This following should become part of a future testnet spec, probably Rome.
Motivation
One concern raised during the specification of the Acropolis testnet is that there currently is no mechanism for preventing misbehaving Liaison storage nodes from storing arbitrary content under any given ContentId
. There are several ways for marking content as valid:
ContentId
be a hash over the content. This validates the content, but not the uploader.ContentId
be a signature over the content. This validates the content and the uploader.For the quick reasons outlined above, the proposal is to go with the last option.
Signing Scheme
Substrate uses ed25519
or sr25519
keys, so signing with them seems like the simplest option. The uploader of a DataObject
already registers themselves as the owner of this DataObject
, meaning all relevant information for verifying a signature with this ID is already available to consumers of DataObject
.
The only considerations for not using this ownership ID are:
For these reasons, the suggestion is to introduce a signing_pubkey
field to DataObject
that holds a self-describing public key where the corresponding secret/private key has been used to sign the content.
The downside of this approach is that verifying a creator is now possible, but not that the creator is actually the same person as the owner
of the DataObject
. A future extension to the runtime might include a full-blown Public Key Infrastructure for this purpose, but that's beyond the scope of the storage module.
On the other hand, the clear upside is that we buy ourselves future use-cases where entirely ephemeral keys are used per DataObject
, or organizations comprised of many accounts use the same key pair for creating assets.
Upload Changes
DataObject
creation must now include the signing_publickey
.Download Changes
There is some issue here with regards to streaming content: a consuming app may want to start rendering video or audio before transmitting all content data, making verifying the signature at the consumption stage less feasible. The proposed scheme assumes that playback and verification of content are two distinct use cases, and shouldn't be necessary concurrently.
Further Considerations
ContentId
would have to map to a sequence of ChunkId
on the runtime, each to be signed and stored independently. On the consuming side, re-assembling the stream after validating each chunk is not without pain either.
The current thinking is that verification can be arbitrarily complex, and include scanning for the right kind of data, etc. Verifying signatures is really more of a low hanging fruit/first stab at this.