chainstack · akegaviar · May 21, 2025 · May 21, 2025
diff --git a/docs/blob-transactions-the-hard-way.mdx b/docs/blob-transactions-the-hard-way.mdx
@@ -3,10 +3,10 @@
 ---

 **TLDR:**
 * Walks you through crafting and broadcasting blob (type-3) transactions on Ethereum, including creating 128 KB blobs and verifying the KZG commitment and blob versioned hash.
 * Explains how blob data is stored on the consensus layer for 18 days, while the blob versioned hash lives on the execution layer.
 * Dives into EIP-4788 & EIP-4844, detailing how to map execution-layer blocks to consensus-layer slots to fetch and verify blob data.
-* Provides full Python scripts for a “bare bones” approach to building, sending, and verifying blob transactions from start to finish.
+* Provides full Python scripts for a "bare bones" approach to building, sending, and verifying blob transactions from start to finish.
 
 ## Main article
 
@@ -17,7 +17,7 @@
 <Check>
  ### Chainstack Ethereum archive nodes store blob data

  Chainstack Ethereum archive nodes store blob data beyond 18 days on the Mainnet, Hoodi, Sepolia, Holesky.

  [Start for free](https://console.chainstack.com/) and get your app to production levels immediately. No credit card required. You can sign up with your GitHub, X, Google, or Microsoft account.
 </Check>
@@ -26,20 +26,20 @@

 ### EIPS involved

 The two EIPs for this guide are:

 * [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) — each block on the execution layer now contains the parent beacon's block root.
 * [EIP-4844](https://www.eip4844.com/) — the compressed transaction data from rollups is now stored on the consensus layer for 18 days.

 There's more to each of these EIPs, but we focus on what we need to know for this guide.

 ### Problem

 A quick reminder on the problem that the blob transactions solve.

 With the increased activity on the Ethereum mainnet, the limited throughput leads up to the increased transaction fees (and costs as ETH appreciates in value). To solve this, a new chain is launched. The new chain has faster block times and a centralized unit (the sequencer) processing the transactions and blocks. To have some of the Ethereum network security & decentralization, the new chain takes all of its transactions as complete transaction data, compresses them (or rolls them up, hence rollups) and posts the data in batches to the Ethereum network as smart contract call data.

 Posting as call data is costly, but you now have the costs split between all the transactions on the rollup chain that were compressed and posted as one transaction to the Ethereum network. As an example, have a look at the Arbitrum batch [517392](https://arbiscan.io/batch/517392?isnitro=true) — there are 809 transactions in the batch; these transactions were paid for in ETH on the Arbitrum mainnet. The ETH from the transactions in the batch was used to fund [one transaction](https://etherscan.io/tx/0x7a5c81cbbc07c68abf0b9d91bb8c6d121aaf3b25b49cd4f047603b3fa9d39910) on the Ethereum mainnet where it posted the entire compressed data from the 809 transactions as call data to a contract. In a simplified way, now you have the cost of this one Ethereum transaction split between the actors of the 809 Arbitrum transactions. This makes each of the 809 transactions cheaper.

 The two problems with this are:

@@ -50,7 +50,7 @@

 Enter blob transactions — the simple and sane solution. Blob data is moved to be stored on the consensus layer. Blob data is no longer processed by the EVM, which means it can be much bigger in size and there is no associated EVM processing gas costs.

 |                   | Blockspace      | Blobspace       |
 | ----------------- | --------------- | --------------- |
 | Seen by all nodes | Yes             | Yes             |
 | Storage           | Execution layer | Consensus layer |
@@ -63,17 +63,17 @@
 A few quick things on blob transactions:

 * Blob transactions are type-3 transactions on the execution layer.
 * When submitted on the execution layer, blob transactions go through the usual lifecycle (node > mempool > block) but the actual blob data is separately gossiped to the consensus layer.
 * Blob data is not validated in the rollup chain context by the Ethereum chain.
 * 18 days is theoretically sufficient for all the network participants to agree on the rollup chain state.
 * It is ultimately the job of the respective rollup chain mechanisms to store the blob data beyond 18 days and ensure its availability (aka Data Availability).
 * Even though the blob data is stored for 18 days, the KZG commitment for each blob — which is basically a fancy hash of blob data — is stored forever. This means that if you recover a blob that's been lost, you can prove it's the same blob through the respective KZG commitment.

 ### Transaction types

 As mentioned, blob transactions are type-3 transactions and at the time of this post are the latest transaction type.

 * **Type-0** aka Legacy — original Ethereum transactions with the parameters `nonce`, `gasPrice`, `gasLimit`, `to`, `value`, `data`, `v`, `r`, `s`.

 * **Type-1** aka Access list — adds the `accessList` parameter to the original set. Introduced by [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930).

@@ -84,17 +84,17 @@
  * `maxFeePerBlobGas` — max fee per blob gas to store the blob
  * `blobVersionedHashes` — a blob pointer, which is a hash of the blob's KZG commitment

 As you see, Ethereum transactions add more parameters with each new type.

 ## Walkthrough

 Now let's have a hands-on walkthrough. In Python.

 Here's what we are going to do:

 * Create our own blob data

 * Send a type-3 transaction with our blob data on Sepolia

 * Retrieve our blob data from the network

@@ -117,7 +117,7 @@

 <Steps>
  <Step>
    Log in to your [Chainstack account](https://console.chainstack.com/) and get an Ethereum Sepolia node. You can get by with a full node for this exercise.
  </Step>
  <Step>
    Install [eth-abi](https://pypi.org/project/eth-abi/).
@@ -132,7 +132,7 @@
    Install [ckzg](https://pypi.org/project/ckzg/) — this computes the KZG commitments.
  </Step>
  <Step>
    Fund your account with SepoliaETH. You can do this through the [Chainstack faucet](https://faucet.chainstack.com/).
  </Step>
  <Step>
    Create a `.env` file with the following variables:
@@ -156,11 +156,11 @@
 <CodeGroup>
  ```python Python
  import os
  from eth_abi import abi

  def create_blob_data(text):
      # Encode the text using Ethereum ABI encoding for a string
      encoded_text = abi.encode(["string"], [text])

      # Calculate the required padding to make the blob size exactly 131072 bytes or 128 KB
      required_padding = 131072 - (len(encoded_text) % 131072)
@@ -171,7 +171,7 @@
      return BLOB_DATA

  def main():
      text = "Chainstack" # If you change this, make sure you update the padding

      # Create blob data
      blob_data = create_blob_data(text)
@@ -204,9 +204,9 @@
 <CodeGroup>
  ```python Python
  import os
  from eth_abi import abi
  from eth_account import Account
  from eth_utils import to_hex
  from web3 import Web3, HTTPProvider
  from dotenv import load_dotenv

@@ -216,33 +216,33 @@

  """
  Add the web3py middleware to ensure compatibility with Erigon 2
  as the eth_estimateGas only expects one argument. The block number or
  block hash was dropped in https://github.com/ledgerwatch/erigon/releases/tag/v2.60.1
  """
  def erigon_compatibility_middleware(make_request, w3):
      def middleware(method, params):
          if method == 'eth_estimateGas' and len(params) > 1:
              # Modify the params to include only the transaction object
              params = params[:1]
          return make_request(method, params)
      return middleware
  w3.middleware_onion.add(erigon_compatibility_middleware)

  text = "Chainstack"
  encoded_text = abi.encode(["string"], [text])

  # Calculate the required padding to make the blob size exactly 131072 bytes
  required_padding = 131072 - (len(encoded_text) % 131072)

  # Create the BLOB_DATA with the correct padding
  BLOB_DATA = (b"\x00" * required_padding) + encoded_text

  pkey = os.environ.get("PRIVATE_KEY")
  acct = w3.eth.account.from_key(pkey)

  tx = {
      "type": 3, # Type-3 transaction
      "chainId": 11155111,  # Hoodi 560048; Sepolia 11155111; Holesky 17000
      "from": acct.address,
      "to": "0x0000000000000000000000000000000000000000", # Does not matter what account you send it to
      "value": 0,
@@ -253,13 +253,13 @@
  }

  # Now you can estimate gas as usual
  gas_estimate = w3.eth.estimate_gas(tx)
  tx["gas"] = gas_estimate

  # Proceed with the rest of your script
  signed = acct.sign_transaction(tx, blobs=[BLOB_DATA])
  tx_hash = w3.eth.send_raw_transaction(signed.raw_transaction)
  tx_receipt = w3.eth.wait_for_transaction_receipt(tx_hash)
  print(f"TX receipt: {tx_receipt}")
  ```
 </CodeGroup>
@@ -302,7 +302,7 @@
 
 Since we are working with the consensus layer now, make sure you now use the consensus client endpoint from your Chainstack node details.
 
-Our example transaction is included in [block 6090748](https://sepolia.etherscan.io/txs?block=6090748\&isblob=true) on the execution layer. The call we are going to use is [Retrieve blob sidecar](/reference/ethereum_beacon_chain_api/state/getBlobSidecarByRoot).
+Our example transaction is included in [block 6090748](https://sepolia.etherscan.io/txs?block=6090748&isblob=true) on the execution layer. The call we are going to use is [Retrieve blob sidecar](/reference/getblobsidecarbyslot).
 
 To provide a specific pointer for the blob data on the consensus layer, we can use one of the following:`head`, `genesis`, `finalized`, or `slot_number`.
 
@@ -320,7 +320,7 @@
   ```
 </CodeGroup>
 
-This will retrieve all the four blobs referenced by the four type-3 transactions in [block 6090748](https://sepolia.etherscan.io/txs?block=6090748\&isblob=true) on the execution layer. One of them is our blob data.
+This will retrieve all the four blobs referenced by the four type-3 transactions in [block 6090748](https://sepolia.etherscan.io/txs?block=6090748&isblob=true) on the execution layer. One of them is our blob data.
 
 ### Compute the KZG commitment
 
@@ -415,9 +415,9 @@
   ```
 </CodeGroup>
 
-Remember that the blob versioned hash is stored on the execution layer. To retrieve it, you can do a simple [eth\_getTransactionByHash](/reference/ethereum_node_api/transaction_info/eth_getTransactionByHash).
+Remember that the blob versioned hash is stored on the execution layer. To retrieve it, you can do a simple [eth\_getTransactionByHash](/reference/ethereum-gettransactionbyhash).
 
 Example for our transaction on Sepolia:
 
 <CodeGroup>
  ```shell Shell
@@ -433,7 +433,7 @@
    "params": [
      "0x5a74bd72aeeb99e874e58b927f9a5c96665278a36b61bed69a4b09597b02edce"
    ]
  }' | jq '.result.blobVersionedHashes'
  ```
 </CodeGroup>

@@ -459,7 +459,7 @@
  block = w3.eth.get_block(block_number, full_transactions=True)

  # Iterate through transactions and check for type-3 transactions
  for tx in block.transactions:
      if tx.type == 3:  # Type 3 refers to blob transactions
          print("Transaction Hash:", tx.hash.hex())
  ```
@@ -632,13 +632,13 @@

 ## Conclusion

 This hands-on the hard way guide walked you through creating, detecting, and verifying the type-3 transactions (aka blob transactions). It also showed you some of the pitfalls and how to navigate them like getting slot number associated with the execution layer blob transaction, being able to retrieve the blobs through the Nimbus client, blob data being stored for 18 days (unless you run archive nodes with Chainstack), and so on.

 ### About the author

 <CardGroup>
  <Card title="Ake" img="/images/docs/profile_images/1719912994363326464/8_Bi4fdM_400x400.jpg">
    <Icon icon="code"  iconType="solid"/>Director of Developer Experience @ Chainstack

    <Icon icon="screwdriver-wrench"  iconType="solid"/>  Talk to me all things Web3


diff --git a/docs/yellowstone-grpc-geyser-plugin.mdx b/docs/yellowstone-grpc-geyser-plugin.mdx
@@ -2,9 +2,9 @@
 title: "Yellowstone gRPC Geyser plugin"
 ---

 _Solana is fast. Geyser is faster._

 Yellowstone gRPC Geyser is a high-speed, plugin-based interface that streams live Solana blockchain data directly from validator memory, eliminating the latency of traditional RPC methods.

 <Check>
  ### Geyser is available starting from Growth
@@ -24,16 +24,30 @@

 <Steps>
 <Step>
 Deploy a Solana [Global Node](/docs/global-elastic-node)
 </Step>
 <Step>
 Click on your deployed Solana node.
 </Step>
 <Step>
 Click **Add-ons** > **Yellowstone gRPC Geyser Plugin** > **Install**.
 </Step>
 </Steps>
 
+## Limits
+
+$149/month:
+* Unlimited stream events
+* 5 streams available per platform account
+* Up to 50 Solana accounts per stream
+
+$449/month:
+* Unlimited stream events
+* 25 streams available per platform account
+* Up to 50 Solana accounts per stream
+
+Note that on a dedicated Solana node with Yellowstone gRPC Geyser plugin limit customization is available.
+
 ## Tooling
 
 See: