Releases: cardano-community/pg_cardano
v1.0.5-p1 Better CBOR<->JSONB conversion
This is quite an important release for several reasons:
KOIOS Collaboration & CIP-88 Support
Our friends at KOIOS came up with the idea of implementing a function for convenient validation of key registration according to their proposed CIP-88 standard. This release owes its existence to that collaboration.
It has a rather unusual tag: v1.0.5-p1, where p1 stands for "phase 1". This is a full-fledged release, not a beta—it is simply divided into two phases.
- Phase 1 introduces the implementation of
tools_verify_cip88_pool_key_registrationas an SQL procedure that utilizes multiple calls to native code instead of a fully native implementation. Essentially, this is a prototype, but one that is production-ready and fully tested. - Phase 2 (
v1.0.5-p2) will provide the same functionality but as a purely native implementation, without changing the function signature. The only difference will be improved performance. 🚀
CBOR<->JSONB Improvements
During development, we uncovered several inconsistencies in repeated CBOR<->JSONB serialization and deserialization, which have now been fixed. This makes the release not just important but also highly beneficial.
-
Enhanced CBOR->JSONB Encoder
- The encoder now properly serializes
byteaas hex-encoded rather than a hex-like string. - This makes CBOR output more compact.
- It also aligns the serialization process with
cardano-cli.
- The encoder now properly serializes
-
Fixing JSONB Bytearray Handling
- JSONB does not have a native
bytearraytype; it is always passed as a hex-encoded string, which, in some cases, was still stored as text. - This limitation has been successfully worked around, making the handling more robust than ever.
- JSONB does not have a native
-
New Function:
cbor_decode_jsonb_hex2bytea- Correct encoding of
byteainto CBOR is important, but so is correct decoding. - Instead of modifying the existing
cbor_decode_jsonbfunction (which could introduce regressions for users), a new function,cbor_decode_jsonb_hex2bytea, was introduced to handle this properly.
- Correct encoding of
Release Notes:
- Fixed the issue with
\u{0}characters in property keys; - JSONB->CBOR conversion now follows the same rules as
cardano-cli; - JSONB->CBOR conversion now correctly handles bytearray transfer between formats;
- CBOR->JSONB conversion now allows handling bytearray transfer between formats with
cbor_decode_jsonb_hex2byteafunction; - Refactoring, lots of refactoring, and some optimizations;
- Added a function
tools_verify_cip88_pool_key_registration; - README.md update;
- Tests update;
- Migrations update;
v1.0.4 - Asset Name Reader implementation
By standard, all asset_name strings should be encoded as hex. However, they could also be just hex, not a UTF-8 string.
Many developers have to use something like this:
CREATE OR REPLACE FUNCTION "convert_asset_name"("name" bytea) RETURNS "varchar"
AS
$$
BEGIN
return convert_from("name", 'utf-8');
EXCEPTION
WHEN character_not_in_repertoire
THEN
return encode("name", 'hex');
END;
$$ LANGUAGE "plpgsql";It works, but it could work better! So, it was reimplemented in Rust to be more robust.
Release Notes:
The tools_read_asset_name function has been added. It helps handle asset_name values that may be either UTF-8 strings or raw hexadecimal values. If the input is valid UTF-8, it is returned as a string. Otherwise, the function encodes it in hex format.
v1.0.3 CIP-105 update implementation
v1.0.2 - \u0000 fix
During testing, it was discovered that some Daedalus addresses (which can contain arbitrary data by design) included so-called "null characters" or \u0000. This is not an issue in terms of protocol or security, but it is problematic for PostgreSQL, which cannot handle this character within JSONB format.
Other extensions for working with CBOR are also subject to this issue.
Release Notes:
- It was decided to remove \u0000 from the decoded text if presents;
v1.0.1 - robust cbor decoding
v1.0.0
Release Notes
This release of the pg_cardano PostgreSQL extension provides a comprehensive set of tools for working with cryptographic operations and Cardano-specific functionalities directly within PostgreSQL:
1. Base58 Encoding/Decoding:
- Encode and decode data using the Base58 encoding scheme, which is widely used in blockchain applications for compact and human-readable representations of binary data.
2. Bech32 Encoding/Decoding:
- Supports encoding and decoding of Bech32, a common format used in Cardano for addresses and other data structures.
3. CBOR (Concise Binary Object Representation) Encoding/Decoding:
- Enables encoding of JSONB objects into CBOR format and decoding CBOR data back into JSONB format.
4. Blake2b Hashing:
- Provides Blake2b cryptographic hashing, which allows users to hash data with an output length configurable between 1 and 64 bytes.
5. Ed25519 Digital Signatures:
- Allows creation of Ed25519 signatures using a provided secret key, as well as verification of signatures using the corresponding public key.
6. Cardano-specific Tools:
DRep ID Builders (CIP-105 and CIP-129 Support):
- The extension supports the encoding of DRep IDs (Delegated Representative Identifiers) using both CIP-105 and CIP-129 formats.
Shelley Address Builders and Extractors:
- Create Shelley-era addresses (base, enterprise, reward) using payment and/or stake credentials, with support for both keyhash and script credentials.
- Extract payment and stake credentials from Bech32 Shelley addresses.
- Identify the type of Shelley address (e.g., payment-key, stake-key, script-key, etc.), making it easier to categorize and process addresses within PostgreSQL queries.