BlobStore is the principle smart contract system for Link. All base content is registered with BlobStore. IPFS is used as the storage layer.
BlobStore has the following properties:
- The approximate time that every blob is published is recorded on the blockchain.
- Every blob published can be read by anyone. The only way to avoid this would be to encrypt the blob before publishing it.
- While a blob can be “retracted”, it can never really be deleted because the transaction that created it will be archived for eternity on full nodes.
- BlobStore has a rudimentary revisioning system built-in where a blob can have multiple revisions, e.g. for editing posts. More sophisticated revisioning systems can be built on top of BlobStore where each blob is a revision.
- Each blob can have an owner. Only the owner can modify a blob, change blob settings, or transfer ownership to another address.
- Each blob has the following flags that can be set:
- The contents of the blob can be changed. Once disabled this flag cannot be re-enabled.
- Enfore Revisions
- When updating the blob a new revision must be created. It is not possible to retract revisions. Once enabled, this flag cannot be disabled.
- The blob in its entirety can be retracted. This is unaffected by Enforce Revisions. The blobId of a retracted blob can never be used again. Once disabled this flag cannot be re-enabled.
- The blob can be transfered to another user (if they accept it), or disowned completely. Once disabled this flag cannot be re-enabled. At creation time blobs can also be flagged as anonymous to not have an owner associated. An alternative to transferable blobs is to use a proxy account with transferable ownership as the blob owner.
- Only a bare-minimum of information is stored in contract state. IPFS is used for actual content storage.
- BlobStore is an upgradable system. Due to a security vulnerability, new storage system, or gas cost improvements a new BlobStore contract may be deployed.
- Unit tests
- BlobStore has tests written in Solidity using the Dapp framework.
Each blob has a 20 byte blobId that is unique to the contract that generated it. The blobId can be further classified to indicate which contract and blockchain the blob is on.
There is considered to be an ordered list of BlobStore contracts. For example, the first contract would be #0. The next one would be #1. 20 byte blobIds can be prefixed to indicate which contract the blob is in, or this can be assumed from context.
Client software should have a hard coded whitelist of BlobStore contracts that its knows how to read from.
New BlobStore contracts register with the BlobStore registration contract. When a blobId is stored in a smart contract, it must be stored with the 12 byte BlobStore contractId. This way the smart contract can look up the address of any BlobStore contract in the registration contract. This is essential to future-proof smart contracts that need to communicate with BlobStore contracts.
All current deployments of BlobStore contracts on Link were compiled with Solidity 0.4.11 with optimizations enabled.
BlobStoreRegistry contract address:
IPFS with SHA256 hash.