v0.43.0 #2800
steven-sheehy
started this conversation in
Releases
v0.43.0
#2800
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Smart Contracts
With Hedera's increased focus on Smart Contracts, we took the time to revamp the mirror node's smart contract support and lay the groundwork for future enhancements. As detailed in the design document, plans include new contract-specific REST APIs and Ethereum-compatible APIs in the future.
To prepare for that, the database schema and importer were updated to normalize and store all contract-related information, fixing long-standing bugs like not storing contract bytecode and child contracts. The contract table was split from the generic entity table and work was started on making all the entity tables maintain a history of all changes. The REST API now supports searching for and retrieving specific contracts. Below is an example of retrieving a contract:
/api/v1/contracts/{id}{ "admin_key": { "_type": "ProtobufEncoded", "key": "7b2233222c2233222c2233227d" }, "auto_renew_period": 7776000, "bytecode": "0xc896c66db6d98784cc03807640f3dfd41ac3a48c", "contract_id": "0.0.10001", "created_timestamp": "1633466229.96874612", "deleted": false, "expiration_timestamp": "1633466229.96874612", "file_id": "0.0.1000", "memo": "First contract", "obtainer_id": "0.0.101", "proxy_account_id": "0.0.100", "solidity_address": "0x00000000000000000000000000000000000003E9", "timestamp": { "from": "1633466229.96874612", "to": "1633466568.31556926" } }Data Architecture
Over the last few months, work has been underway to analyze possible
PostgreSQLreplacements as the need for handling an ever-increasing amount of data puts strain on the existing mirror node database. After agreeing upon the acceptance criteria any new solution must meet, priority was placed on a PostgreSQL-compatible distributed database that can shard our time-series data across many nodes for scale-out reads and writes. That would ensure the quickest time to market and ease transition for Hedera and others using the open source mirror node software. The four distributed database we choose for our proof of concept included CitusDB, CockroachDB, TimescaleDB, and YugabyteDB.After a detailed analysis of each, we chose CitusDB for our next database due to its excellent PostgreSQL compatibility (it's a PostgreSQL extension) and its mature support for sharding time-series data. Its distributed query engine routes and parallelizes DDL, DML, and other operations on distributed tables across the cluster. And its columnar storage can compress data up to 8x, speeds up table scans, and supports fast projections. This release contains some foundational work to get our schema ready for partitioning. You can track our progress as we work towards integrating CitusDB into our codebase over the next few months. We plan on maintaining support for both databases for a period of time after the work is complete.
Performance Improvements
As is usually the case, we took the time to optimize various pieces of the system to work at scale. Our transactions REST API saw some performance improvements by rewriting them using Common Table Expressions (CTE). This will pay future dividends with CitusDB as it allows queries to be ran in parallel easier. An issue with
/api/v1/topics/{id}/messagestiming out for some topics was addressed and the realm and topic number columns were combined to reduce the table and index size./api/v1/tokens/{id}/balancesalso saw some performance improvements that decreased its average response time. Configuration options for faster historical ingestion were documented so that mirror node operators can get historical data faster.Enhancements
Bug Fixes
Dependency Upgrades
Contributors
We'd like to thank all the contributors who worked on this release!
This discussion was created from the release v0.43.0.
Beta Was this translation helpful? Give feedback.
All reactions