@ -62,3 +62,15 @@ To calculate the amount of BTC to send miners should:
- Guess the price BTC/STX for the next day (100 blocks later)
- Guess the total amount of BTCs committed by all miners
## Microblocks
Unlike most existing blockchains, Stacks blocks are not produced atomically. Instead, leaders may dynamically package transactions into a sequence of microblocks as they are received from users.
A leader can "stream" a block over the course of its tenure by selecting transactions from the mempool as they arrive and packaging them into microblocks. These microblocks contain small batches of transactions, which are organized into a hash chain to encode the order in which they were processed. If a leader produces microblocks, then the new chain tip the next leader builds off of will be the last microblock the new leader has seen.
The advantage of the streaming approach is that a leader's transaction can be included in a block during the current epoch, reducing latency.
Whether a transactions should be included in a microbloc can be [defined in the transaction encoding](/understand-stacks/transactions#anchor-mode).
> More details can be found in [SIP001](https://github.com/stacksgov/sips/blob/main/sips/sip-001/sip-001-burn-election.md).
@ -48,12 +48,16 @@ Nonces are added to all transactions and help identify them in order to ensure t
When a new [token transfer transaction](/understand-stacks/transactions#stacks-token-transfer) is constructed, the most recent nonce of the account needs to fetched and set.
> The API provides an endpoint to [simplify nonce handling](/understand-stacks/stacks-blockchain-api#nonce-handling).
## Confirmations
The Stacks 2.0 network is anchored onto the bitcoin network. This allows transactions on Stacks to inherit the same finality and security of the Bitcoin blockchain.
The time to mine a block, to confirm transactions, will eventually match the expected "block time" of the bitcoin network: 10 minutes.
> Transactions can also be mined in microblocks, reducing the latency significantly. Learn more [here](/understand-stacks/transactions#anchor-mode).
The block time is hardcoded and will change throughout the implementation phases of the [testnet](/understand-stacks/testnet). The current block time can be obtained through the [`GET /extended/v1/info/network_block_times`](https://blockstack.github.io/stacks-blockchain-api/#operation/get_network_block_times) endpoint:
@ -290,6 +298,65 @@ This API supports [v1.4.6 of the Rosetta specification](https://www.rosetta-api.
-> Find all Data and Construction Rosetta endpoints [here](https://blockstack.github.io/stacks-blockchain-api/#tag/Rosetta)
## Microblocks support
!> API support for [microblocks](/understand-stacks/mining#microblocks) is current being worked on. New API endpoints are documented [here](https://stacks-blockchain-api-git-feat-microblocks-blockstack.vercel.app/#tag/Microblocks). The details are subject to change for now.
The [transaction anchor mode](/understand-stacks/transactions#anchor-mode) defines if a transaction should be included in a microblock. If so, the latency for a transaction to be confirmed can be reduced.
The API allows querying the most recently streamed microblocks:
Microblocks are a trdeoff between finality and latency. The initial confirmation of a transaction inside a microblock does not imply finality. Microblocks are subject to reorganization. Thus, the order of processing for confirmed transactions can change. Only once the microblock was added to an anchor block, finality can be assumed.
## Nonce handling
Developer have to keep track of the last nonce used in a transaction. The API provides an endpoint to make nonce handling simpler:
You can use the `possible_next_nonce` property as the nonce for your next transaction.
## Running an API server
While Hiro provides a hosted API server of the Stacks Blockchain API, anyone can spin up their own version. Please follow the instructions in this guide to start a Docker container with the API service running:
@ -61,6 +61,7 @@ description: Summary of technical specifications of Stacks 2.0
1. _originating account_ is the account that creates, _authorizes_ and sends the transaction
2. _paying account_ is the account that is billed by the leader for the cost of validating and executing the transaction
3. _sending account_ is the account that identifies who is currently executing the transaction: this can change as a transaction executes via the `as-contract` Clarity function
- Transactions can be batched or streamed into blocks. The behavior can be controlled by the anchor mode of a transaction. With streaming (microblocks), a faster confirmation time is possible.
- Two types of authorizations: standard authorization is where originating account is the same as paying account. _Sponsored_ authorization is where originating account and paying account are distinct. For instance, developers or service providers could pay for users to call their smart-contracts.
- For sponsored authorization, first a user signs with the originating account and then a sponsor signs with the paying account.
- Mempool limit for concurrent pending transactions is 25 per account
@ -51,6 +51,39 @@ A sample of each transaction type can be found in the [Stacks Blockchain API res
~> Read-only contract call calls do **not** require transactions. Read more about it in the [network guide](/understand-stacks/network#read-only-function-calls).
## Anchor mode
Transactions can be mined either in an anchor block or in a microblock. If microblock-anchoring is selected, the transaction can be confirmed much quicker that the target block time. However, microblocks can be subject to re-organization, thus changing the order of transaction processing:
If your transaction relies on a state that could be altered by a previous transactions with serious implications, you should carefully evalute if microblock-anchoring should be set.
The anchor mode has three options:
- `OnChainOnly` The transaction MUST be included in an anchored block
- `OffChainOnly`: The transaction MUST be included in a microblock
- `Any`: The leader can choose where to include the transaction
Here is an example where the transaction must be included in a microblock:
```js
import { AnchorMode, makeSTXTokenTransfer } from '@stacks/transactions';
import { StacksTestnet, StacksMainnet } from '@stacks/network';
Transaction post-conditions are a feature meant to limit the damage malicious smart contract developers and smart contract bugs can do in terms of destroying a user's assets. Post-conditions are executed whenever a contract is instantiated or a public method of an existing contract is executed. Whenever a post-condition fails, a transaction will be forced to abort.
@ -304,35 +337,37 @@ When called the Stacks Blockchain API or Node RPC API, transactions returned wil
Alexander Graebe
4 years ago
Patrick Gray
