34 DBMS_BLOCKCHAIN_TABLE
A blockchain table is an append-only table designed for centralized
blockchain applications. The DBMS_BLOCKCHAIN_TABLE
package allows
you do the following: delete rows in a blockchain table that are beyond the row
retention defined for the blockchain table; get the bytes that are input to the
cryptographic hash for a row so you can verify the hash in the row; sign a row you
inserted into a blockchain table after the row is added to a chain in the blockchain
table; and have the database verify the hashes on some or all rows in a blockchain
table. Blockchain tables support only DER
encoding for
X.509
certificates, not PEM
encoding.
This chapter contains the following topics:
- DBMS_BLOCKCHAIN_TABLE Overview
- DBMS_BLOCKCHAIN_TABLE Security Model
- Summary of DBMS_BLOCKCHAIN_TABLE Subprograms
See Also:
- For information on hidden columns in blockchain tables, see Hidden Columns in Blockchain Tables
34.1 DBMS_BLOCKCHAIN_TABLE Overview
In Oracle Blockchain Table, peers are database users who trust the database to maintain a tamper-resistant ledger.
The ledger is implemented as a blockchain table, which is defined and managed by the application. Existing applications can protect against fraud without requiring a new infrastructure or programming model. Although transaction throughput is lower than for a standard table, performance for a blockchain table is better than for a decentralized blockchain.
DBMS_BLOCKCHAIN_TABLE
package lets you do the following:
- delete rows in a blockchain table that are beyond the row retention defined for the blockchain table
- get the bytes that are input to the signature algorithm so you can sign a row you inserted into the blockchain table
- get the bytes that are input to the cryptographic hash for a row so you can verify the hash in the row
- sign a row you inserted into a blockchain table after the row is added to a chain in the blockchain table
- have the database verify the hashes and signatures on some or all rows in a blockchain table.
34.2 DBMS_BLOCKCHAIN_TABLE Security Model
The DBMS_BLOCKCHAIN_TABLE
package is owned by SYS
and is installed as part of database installation. The routines in the package are run with invokers' rights (run with the privileges of the current user). Thus any user with select privileges on the blockchain table should be able to validate the row contents of that table.
Any user with delete privileges on the blockchain table can delete rows beyond the retention period defined for the blockchain table.
A user that inserted a row into the blockchain table can add a digital signature to the row after the row is added to a chain in the blockchain table.
34.3 Summary of DBMS_BLOCKCHAIN_TABLE Subprograms
The DBMS_BLOCKCHAIN_TABLE
package uses DELETE_EXPIRED_ROWS
, GET_BYTES_FOR_ROW_HASH
, GET_BYTES_FOR_ROW_SIGNATURE
, SIGN_ROW
, and VERIFY_ROWS
subprograms to perform various functions.
Table 34-1 DBMS_BLOCKCHAIN_TABLE Package Subprograms
Subprogram | Description |
---|---|
DELETE_EXPIRED_ROWS Procedure | Deletes rows outside the retention window created before before_timestamp if the time stamp is specified; otherwise, deletes all rows outside the retention window.
|
GET_BYTES_FOR_ROW_HASH Procedure | Returns in row_data the bytes (series of {meta-data-value} {column-data-value} in column position order} for the particular row identified, followed by the hash (in data format) for previous row in the chain, in the data format supported.
|
GET_BYTES_FOR_ROW_SIGNATURE Procedure | The bytes returned are the bytes in the row hash. No metadata is included. |
SIGN_ROW Procedure | This procedure can be used by the current user to provide a signature on row content of a previously inserted row. The user who inserted a row into a blockchain table is the only user that can sign the row. |
VERIFY_ROWS Procedure | Verifies all rows on all applicable chains for integrity of HASH column value for rows created in the range of LOW_TIMESTAMP to HIGH_TIMESTAMP . Row signatures can be verified as an option.
|
34.3.1 DELETE_EXPIRED_ROWS Procedure
This procedure deletes rows outside the retention window created before_timestamp
if the time stamp is specified; otherwise, deletes all rows outside the retention window. The number of rows deleted is returned in number_of_rows_deleted
parameter.
Syntax
DBMS_BLOCKCHAIN_TABLE.DELETE_EXPIRED_ROWS( schema_name IN VARCHAR2, table_name IN VARCHAR2, before_timestamp IN TIMESTAMP WITH TIME ZONE DEFAULT NULL, number_of_rows_deleted OUT NUMBER);
Parameters
Table 34-2 DELETE_EXPIRED_ROWS Procedure Parameters
Parameter | Description |
---|---|
|
The name of the schema. |
table_name |
The name of the blockchain table. |
before_timestamp |
The end time for the range of rows deleted by the procedure, subject to the row retention time currently associated with the blockchain table. This is an optional parameter. The default value is |
number_of_rows_deleted |
The count of the number of rows deleted. |
34.3.2 GET_BYTES_FOR_ROW_HASH Procedure
This procedure returns the bytes in column_data
that the
database hashed to get the hash value for the row identified by parameters
instance_id
, chain_id
, and sequence_id
.
These bytes are a concatenation of metadata and data bytes for each column of the table in
column position order, followed by the hash value for the previous row in the
chain.
Syntax
DBMS_BLOCKCHAIN_TABLE.GET_BYTES_FOR_ROW_HASH( schema_name IN VARCHAR2, table_name IN VARCHAR2, instance_id IN NUMBER, chain_id IN NUMBER, sequence_id IN NUMBER, data_format IN NUMBER, row_data IN OUT BLOB);
Parameters
Table 34-3 GET_BYTES_FOR_ROW_HASH Procedure Parameters
Parameter | Description |
---|---|
schema_name |
The name of the schema. |
table_name |
The name of the blockchain table. |
instance_id |
The instance that inserted the row. Valid values are |
chain_id |
The chain containing the row. There are 32 chains in each instance, and they are numbered from 0 to 31. |
sequence_id |
The position of the row on the specified chain. |
data_format |
The version of the data layout for the hash in the specified row. Must be 1 in this release.
|
row_data |
The bytes for the specified row in the specified data format that can be input to the cryptographic hash function to verify the value of the hash in the row. Any bytes in the BLOB are overwritten.
|
Usage Notes
All parameters are required input parameters.
The metadata bytes for a column are 20 bytes that encode the blockchain algorithm
version used to hash the row, the column position, the column data type, whether the
column value is NULL
, and the actual length of the column value in
bytes.
The column data bytes are the actual bytes representing the column value on disk for
non-character columns. For character columns, the values are normalized to specific
character sets. For CHAR
and NCHAR
columns, blank
trimming is also done.
Few metadata bytes are reserved for future use.
34.3.3 GET_BYTES_FOR_ROW_SIGNATURE Procedure
The routine returns in row_data
the bytes in the hash in the row without any metadata. No other columns are involved either in the row or in the previous row.
Syntax
DBMS_BLOCKCHAIN_TABLE.GET_BYTES_FOR_ROW_SIGNATURE( schema_name IN VARCHAR2, table_name IN VARCHAR2, instance_id IN NUMBER, chain_id IN NUMBER, sequence_id IN NUMBER, data_format IN NUMBER, row_data IN OUT BLOB);
Parameters
Table 34-4 GET_BYTES_FOR_ROW_SIGNATURE Procedure Parameters
Parameter | Description |
---|---|
|
The name of the schema. |
table_name |
The name of the blockchain table. |
instance_id |
The instance on which the row was inserted. Valid values are |
chain_id |
The chain on which the row was inserted. There are 32 chains in each instance, and they are numbered from 0 to 31. |
sequence_id |
The position of the row on the chain. |
data_format |
The format of the data in row_data . The value must be 1 in the DB20c release.
|
row_data |
A sequence of bytes that must be signed. |
Usage Notes
All parameters are required input parameters.
34.3.4 SIGN_ROW Procedure
This procedure can be used by the current user to provide a signature on row content of a previously inserted row. The transaction that inserted the row into the blockchain table must have committed before the SIGN_ROW
procedure is called.
Syntax
DBMS_BLOCKCHAIN_TABLE.SIGN_ROW( schema_name IN VARCHAR2, table_name IN VARCHAR2, instance_id IN NUMBER, chain_id IN NUMBER, sequence_id IN NUMBER, hash IN RAW DEFAULT NULL, signature IN RAW, certificate_guid IN RAW, signature_algo IN NUMBER);
Parameters
Table 34-5 SIGN_ROW Procedure Parameters
Parameter | Description |
---|---|
|
The name of the schema. |
table_name |
The name of the blockchain table. |
instance_id |
The instance on which the row was inserted. |
chain_id |
The chain containing the row to be signed. There are 32 chains in each instance, and they are numbered from 0 to 31. |
sequence_id |
The position of the row on the chain. Valid values are |
hash |
If non-NULL , the expected value of the hash in the row to be signed. If NULL , the hash in the row to be signed is not checked.
|
signature |
The user's digital signature on the hash value stored in the row. |
certificate_guid |
A unique identifier for the certificate stored in the database that may be used to verify the digital signature. |
signature_algo |
The algorithm used to create the digital signature. The algorithm must be one of the following constants defined in the DBMS_BLOCKCHAIN_TABLE package:
|
Note:
For information on hidden columns in blockchain tables, see Hidden Columns in Blockchain TablesUsage Notes
- All parameters are required input parameters except for
hash
. - The database will verify that:
- the current user’s
obj#
matches theuser#
hidden column value (ensures that the user owns the row) - the user has insert privileges for the blockchain table
‘schema_name’.’table_name’
- the hash (if provided) matches the hash column content for the row
- the
signature
column value for the specific row identified by‘instance_id’
,‘chain_id’
, and‘sequence_id’
isNULL
- if the verification succeeds, the signature value is stored for the row.
- the current user’s
34.3.5 VERIFY_ROWS Procedure
Verifies all rows on all applicable chains for integrity of HASH
column value and optionally the SIGNATURE
column value for rows created in the range of low_timestamp
to high_timestamp
. An appropriate exception is thrown if the integrity of chains is compromised.
Syntax
DBMS_BLOCKCHAIN_TABLE.VERIFY_ROWS( schema_name IN VARCHAR2, table_name IN VARCHAR2, low_timestamp IN TIMESTAMP WITH TIME ZONE DEFAULT NULL, high_timestamp IN TIMESTAMP WITH TIME ZONE DEFAULT NULL, instance_id IN NUMBER DEFAULT NULL, chain_id IN NUMBER DEFAULT NULL, number_of_rows_verified OUT NUMBER, verify_signature IN BOOLEAN DEFAULT TRUE);
Parameters
Table 34-6 VERIFY_ROWS Procedure Parameters
Parameter | Description |
---|---|
schema_name |
The name of the schema. |
table_name |
The name of the blockchain table. |
low_timestamp |
If specified, the low end of the time range for verifying rows. The default value is |
high_timestamp |
If specified, the high end of the time range for verifying rows. The default value is |
instance_id |
If specified, restricts row verification to rows inserted on the specified instance. |
chain_id |
If specified, restricts row verification to rows on the specified chain. There are 32 chains in each instance, and they are numbered from 0 to 31. |
number_of_rows_verified |
The number of rows verified. |
verify_signature |
If The default value is |
Usage Notes
- The hash on the first element in the time range for verifying rows in a chain is verified only if its sequence number is
1
. schema_name
andtable_name
are required input parameters- All others input parameters are optional, with the following exceptions:
- If
chain_id
is specified,instance_id
must be specified - Valid values for
instance_id
are 1, 2, … etc. - If neither
instance_id
, norchain_id
is specified, then it implies*all*
chains. If onlyinstance_id
is specified, then it implies*all*
chains on that instance. If both are specified, it implies the specific chain provided by the combination. -
If both
low_timestamp
andhigh_timestamp
are specified, thenhigh_timestamp
must be later thanlow_timestamp
.If
low_timestamp
is not specified, then the range is the oldest row in the blockchain tohigh_timestamp
.If
high_timestamp
is not specified then the range islow_timestamp
to the timestamp of the last row inserted in the table.
- If