Phasing Out of the Debug API
The Bee client has historically utilised two APIs: the main Bee API and the Debug API, which share many of the same endpoints but also have unique functionalities.
In order to streamline future client development and simplify node operation, the two APIs will be merged into the Bee API, and the Debug API will be removed entirely over the following two releases (2.1 and 2.2).⚠️
The Debug API will be phased out and all of its exclusive endpoints will be integrated into the Bee API.
The removal of the Debug API will take part in two phases:
Phase 1 - Bee 2.1:
In the 2.1 release, all exclusive endpoints of the Debug API will be integrated into the Bee API, and the Debug API will be marked as deprecated. This will give node operators and Swarm developers time to remove the Debug API from their setup and move over entirely to the Bee API.
Phase 2 - Bee 2.2:
In the 2.2 release, the Debug API will be entirely removed from the Bee client.⚠️
Warning
Node operators and Swarm developers should use the period between the 2.1 and 2.2 releases to remove the Debug API from their setups and move over entirely to the Bee API in order to avoid any disruptions to their operations.
Changes to the --restricted Option For Bee 2.1
Info
The --restricted option and API authentication feature will be removed entirely in Bee version 2.2.
Along with the merging of the Debug API into the Bee API, changes are being made to the --restricted option. Currently, the --restricted option is used together with the /auth endpoint to control access to business related endpoints on the Bee API (it does not apply to the Debug API). The business related endpoints are not available by default without using the --restricted option and setting up authentication with the /auth endpoint.
In the 2.1 release, the --restricted option will be off by default, and all endpoints except for the authentication related /auth and /refresh endpoints will be available and unrestricted. If a node is started with the --restricted option turned on, the /auth and /refresh endpoints will be available, and the business endpoints will be restricted, requiring a security token generated from the /auth endpoint to access.
Available only when a node is spawned with the --restricted option:
Available by default, can be restricted and protected with basic authentication by enabling the --restricted option:
- /transactions (GET)
- /trasactions/{hash} (GET | POST | DELETE)
- /peers (GET)
- /peers/{address} (DELETE)
- /pingpong/{address} (GET)
- /reservestate (GET)
- /connect/{address} (GET)
- /blocklist (GET)
- /chunks/{address} (GET)
- /toplogy (GET)
- /welcome-message (GET | POST)
- /balances (GET)
- /balances/{peer} (GET)
- /consumed (GET)
- /consumed/{peer} (GET)
- /timesettlements (GET)
- /settlements (GET)
- /settlements/{peer} (GET)
- /chequebook/cheque/{peer} (GET)
- /chequebook/cheque (GET)
- /chequebook/cashout/{peer} (GET | POST)
- /chequebook/balance (GET)
- /chequebook/address (GET)
- /chequebook/deposit (POST)
- /chequebook/withdraw (POST)
- /wallet (GET)
- /wallet/withdraw/{coin} (POST)
- /stamps (GET)
- /stamps/{batchId} (GET)
- /stamps/{batch_id}/buckets (GET)
- /stamps/{amount}/{depth} (POST)
- /stamps/topup/{batch_id}/{amount} (PATCH)
- /stamps/dilute/{batch_id}/{depth} (PATCH)
- /batches (GET)
- /accounting (GET)
- /stake/{amount} (POST)
- /stake (GET | DELETE)
- /redistributionstate (GET)
- /status (GET)
- /status/peers (GET)
- /rchash/{depth}/{anchor1}/{anchor2} (GET)
All other endpoints are unrestricted and are always available.
Localstore Transaction Refactor
The current implementation of localstore transactions (which are responsible for write operations to the chunkstore) is complex, prone to errors, and difficult to maintain. Therefore in 2.1 it is being replaced with LevelDB batch transactions.
The benefits of this change include:
- LevelDB batch transactions allow for transactions to be bundled together in batches rather than executing them one by one. This not only improves efficiency but also reduces the potential for errors.
- By relying on LevelDB batch transactions, the continued maintenance of a custom transaction implementation is no longer required.
This change will improve overall node performance and stability for node operators and Swarm developers.
Freezing Quota Feature
Currently, there is a relatively high probability of nodes getting frozen, even for those honestly participating in the redistribution game. The localstore changes described above are expected to reduce freeze rates by improving the consistency of nodes' reserves. As an additional measure to reduce freeze rates, a freezing quota feature has been added to the newest smart contract, which will be initially disabled at the launch of Bee version 2.1. Based on the impact observed on freezing rates post-release, the freezing quota may be enabled to further decrease freeze occurrences.
Stay Tuned
Don't forget to start preparing early for the 2.1 release, and stay tuned for additional updates over the next two weeks. Make sure you're following us on Twitter for the most up-to-date information, and that you've joined us on Discord to participate in all the latest community discussions.