Gateway

Gates to Arweave network

Arweave gateway is an HTTP accessible service with single purpose: make it easy for users to interact with 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 two AR-IO gateways nodes:

• https://akrd.net - gateway node with cloudfront, optimistic and service caching layers

• https://akrd.io - gateway node with cloudfront and service caching layers

Caching

Serving data directly from Arweave network is not practical for most usecases. To improve performance of 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 to use data uploaded to Arweave before it gets confirmed on chain and before its indexed by Arweave chain indexers. You can use your data milliseconds after 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

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

Sandboxing

When using 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 above example:

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

GraphQL Index

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

GraphQL sandbox urls:

• https://akrd.net/graphql

• https://akrd.io/graphql

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 Limitting

Gateway nodes are rate limitting 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 limitting may be lifted for specific usecases. Supported way of increasing the allowed traffic is including Api-Key header in request. This is custom flow and should be consulted prior to the usage. Don't hesittate to contact us!