Arweave Gateway – AKRD

Gates to Arweave network

An Arweave gateway is an HTTP accessible service with a single purpose: to make it easy for users to interact with the Arweave network.

Features

  • HTTP access to L1 transactions data on Arweave network

  • HTTP access to unbundled transactions data on Arweave network (See bundling)

  • Indexing and serving GraphQL index of transactions

  • HTTP API: https://akrd.io/api-docs

Hosts

Akord maintains an AR-IO gateway node: https://akrd.net

akrd.net is a gateway node with CloudFront, optimistic and service caching layers.

Caching

Serving data directly from the Arweave network is not practical for most use cases. To improve performance of the gateway we offer caching layers:

  • CloudFront cache layer

    Caches content at edge locations closer to users, speeding up delivery by serving subsequent requests from these caches rather than the origin server.

    To omit CloudFront cache layer, you may append a unique query string parameter to the URL for each request e.g.

    https://akrd.net/5CXiXTTcYsvmzGZKz_bHgi_v3propbsj18xM6tEk1zU?timestamp=1620277252

    To forbid storing data in cache use request header Cache-Control: no-cache

  • Optimistic cache layer

    Allows use of data uploaded to Arweave before it gets confirmed on-chain and before it's indexed by Arweave chain indexers. You can use your data milliseconds after its upload. The layer is only active if data is uploaded using Akord bundling service (any Akord entry point: REST API, CLI, SDK, App). There is no TTL for this cache layer. Effectively, that's the source of the data requested the first time (see CloudFront cache layer) from Akord gateway. To omit optimistic cache layer, you should use query parameter optimistic-cache=false e.g. https://akrd.net/5CXiXTTcYsvmzGZKz_bHgi_v3propbsj18xM6tEk1zU?optimistic-cache=false

  • Service cache layer

    The gateway service downloads the transactions data to the local disk and serves those over HTTP. Service layer cache means data is kept on local disk to serve subsequent responses without going to the Arweave network. TTL of this cache is 3 hours. This layer can not be omitted on the request level.

Sandboxing

When using the gateway service you may notice that it does redirects. E.g. when requesting: https://akrd.io/5CXiXTTcYsvmzGZKz_bHgi_v3propbsj18xM6tEk1zU

The gateway service responds with HTTP 301, redirecting to: https://4qs6exju3rrmxzwmmzfm75whqix67xu25cs3wi6xzrgovuje242q.akrd.io/5CXiXTTcYsvmzGZKz_bHgi_v3propbsj18xM6tEk1zU

This is expected behaviour. It is a feature of the gateway, preventing MITM attacks. It is explained in detail in AR-IO Gateway docs. The sandbox id (subdomain hash) is deterministically calculated on service-level based on transaction ID. This is simple Base32 encoding of txID. For the above example:

const id = '5CXiXTTcYsvmzGZKz_bHgi_v3propbsj18xM6tEk1zU';
const expectedTxSandbox = (id): string => {
  return toB32(fromB64Url(id));
};
console.log(expectedTxSandbox); //4qs6exju3rrmxzwmmzfm75whqix67xu25cs3wi6xzrgovuje242q

GraphQL Index

Gateway nodes crawl the Arweave chain block-by-block and index transactions. Akord gateways keep index of Akord bundled transactions and can query the index with the GraphQL API.

GraphQL sandbox urls:

Example request:

query {
 transactions(
        sort: HEIGHT_ASC,
        first: 100,
        after: null,
      tags: [
        {
          name: "Member-Address",
          values: ["os4WnmzUzsghAXP4h+zsfwCdNohcfUy0cJ1bkES42Cc5UQ2MvpL2SeHTxRlf5TfbTFRKSBaBxn72grntYwfweA=="]
        },
        {
          name: "Protocol-Name",
          values: ["Akord"]
        }
      ]
      ) {
        edges {
          cursor
          node {
              id
              tags {
                name
                value
              }
          }
        }
        pageInfo {
          hasNextPage
        }      
    }
}

Rate Limiting

Gateway nodes are rate limiting traffic to block HTTP flood attacks, also known as Denial of Service (DoS).

Allowed non-challenge traffic rate is 1000 requests / 5 minutes per IP.

It means the gateway does not actively block requests when traffic rate is higher. Instead it responds with a challenge that must be solved on client side. This challenge is automatically solved by browser environments. Effectively this rule blocks bot sessions.

Allowed challenge traffic rate is 5000 requests / 5 minutes per IP.

This is maximum, public, per IP traffic on the gateway. When this limit is crossed, gateway blocks requests, responding with HTTP 429. This rule holds even if valid challenge response is provided.

The default rate limiting may be lifted for specific use cases. A supported way of increasing the allowed traffic is by including the Api-Key header in request. This is a custom flow and should be consulted prior to the usage. Don't hesitate to contact us!

Last updated