Merge pull request #9 from ethereum-optimism/gk/env-var-example

Add missing env var to example file + confirm compatibility with Google Cloud Storage

.env.template

@@ -3,6 +3,7 @@
 BLOB_ARCHIVER_L1_BEACON_HTTP=<unset>
 BLOB_ARCHIVER_DATA_STORE=s3
 BLOB_ARCHIVER_S3_ENDPOINT=172.17.0.1:9000
+BLOB_ARCHIVER_S3_CREDENTIAL_TYPE=static
 BLOB_ARCHIVER_S3_ACCESS_KEY=admin
 BLOB_ARCHIVER_S3_SECRET_ACCESS_KEY=password
 BLOB_ARCHIVER_S3_ENDPOINT_HTTPS=false
@@ -14,6 +15,7 @@ BLOB_ARCHIVER_ORIGIN_BLOCK=0x0
 BLOB_API_L1_BEACON_HTTP=<unset>
 BLOB_API_DATA_STORE=s3
 BLOB_API_S3_ENDPOINT=172.17.0.1:9000
+BLOB_API_S3_CREDENTIAL_TYPE=static
 BLOB_API_S3_ACCESS_KEY=admin
 BLOB_API_S3_SECRET_ACCESS_KEY=password
 BLOB_API_S3_ENDPOINT_HTTPS=false

README.md

@@ -10,11 +10,13 @@ allows clients to retrieve blobs from the storage backend
 There are currently two supported storage options:
 
 * On-disk storage - Blobs are written to disk in a directory
-* S3 storage - Blobs are written to an S3 bucket
+* S3 storage - Blobs are written to an S3 bucket (or compatible service)
 
 You can control which storage backend is used by setting the `BLOB_API_DATA_STORE` and `BLOB_ARCHIVER_DATA_STORE` to 
 either `disk` or `s3`.
 
+The `s3` backend will also work with (for example) Google Cloud Storage buckets (instructions [here](https://medium.com/google-cloud/using-google-cloud-storage-with-minio-object-storage-c994fe4aab6b)). 
+
 ### Data Validity
 Currently, the archiver and api do not validate the beacon node's data. Therefore, it's important to either trust the 
 Beacon node, or validate the data in the client. There is an open [issue](https://github.com/base-org/blob-archiver/issues/4)