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:
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:
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