Blockchain
Blockchain Table User Chains
Earlier versions of blockchain tables supported only system chains. A system chain (one of the 32 chains per instance) is randomly chosen by Oracle for every new row inserted into a blockchain table.
A user chain is a chain of rows based on a set of up to three user-defined columns of type NUMBER, CHAR, VARCHAR2, and RAW. For example, consider a blockchain table created for tracking banking transactions (withdrawals, deposits, transfers) associated with various accounts. Assume there is a column called ACCOUNTNO in the blockchain table for account numbers. Each transaction inserts a new entry into this blockchain table for some account number. A user chain can be associated with every unique value in ACCOUNTNO. If there are a total of 100 different account numbers, there can be at most 100 user chains. You can then run a verification procedure only on a chain for a specific ACCOUNTNO, providing greater data isolation. This feature allows you to create user chains for rows in blockchain tables based on version columns even if they are split across system chains.
Multiple user chains increase the flexibility of applying blockchain tables and their verification procedures to make it easier to leverage tamper-resistant tables in your applications.
Blockchain Table Row Versions
The blockchain table row version feature allows you to have multiple historical versions of a row that is maintained within a blockchain table corresponding to a set of user-defined columns. A view <bctable>_last$ on top of the blockchain table allows you to see just the latest version of a row.
This feature allows you to guarantee row versioning when using tamper-resistant blockchain tables in your application.
Blockchain Table Log History
Flashback Data Archive History tables are now blockchain tables. This feature allows changes to one or more regular user tables to be tracked in a blockchain table maintained by the Oracle database as part of the Flashback Data Archive. Each change in a regular table will be added to the blockchain log history table as a separate row within a cryptographic hash chain maintained by the blockchain table. You can verify the data and chain integrity in a Flashback Data Archive Blockchain Log History table using the built-in verification procedures (DBMS_BLOCKCHAIN_TABLE.verify_rows) or through an external verification, including a continuous verification process illustrated by a sample provided in https://github.com/oracle/blockchain-table-samples.
This feature allows you to record changes to regular user tables in a cryptographically secure and verifiable fashion.
Add and Drop User Columns in Blockchain and Immutable Tables
This feature allows evolution of Blockchain and Immutable Tables, namely it allows columns to be added and dropped while maintaining the current data, including that in dropped columns for continuity of crypto-hash chains.
As applications evolve you may need to modify existing tables by adding or dropping columns. In this release, you can easily add or drop columns in previously created Blockchain or Immutable tables. Any rows prior to a column deletion will maintain the data in these columns in order to preserve the integrity of the crypto-hash chains and allow the verification procedures to work across the entire table.
Blockchain Table Countersignature
You can request a database countersignature at the time of signing a row. In addition to recording the countersignature and its metadata in the row, the countersignature and the signed_bytes are returned to the caller. The caller can then save the countersignature and signed_bytes in another data store, such as Oracle Blockchain Platform, for non-repudiation purposes.
A countersignature can provide user additional guarantees that data has been securely stored in the blockchain table.
Blockchain Table Delegate Signer
A delegate is an alternate user who's allowed to sign rows inserted by the primary user. This feature allows a delegate to sign rows in an immutable or blockchain table on behalf of another user. A delegate's signature is accepted only if the signature can be verified using the public key in the delegate's certificate, which has been added to the dictionary table.
A delegate signer can be used when users are not able to sign the rows they created and they trust their delegate.
New Special Privilege Required to Set Long Idle Retention Times for Blockchain and Immutable Tables
Blockchain or immutable tables with idle retention set to a sufficiently large value cannot be dropped until the newest row of the table becomes very old. This limits the ability to drop the blockchain/immutable table if necessary to prevent a disk space exhaustion attack. Hence, the operation of setting a table's idle retention to a large value is restricted to privileged users via a grant of a new TABLE RETENTION system privilege. The idle retention threshold, which specifies when to require the new privilege BLOCKCHAIN_TABLE_RETENTION_THRESHOLD, is configurable.
Ability to create blockchain or immutable tables with long retention times and inserting large amounts of data that can not be deleted could potentially be a vector for a denial of service attack via disk space exhaustion. To reduce this risk, the special privilege has been introduced. Only users granted this privilege can set idle retention above the configurable threshold level.