You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/Introduction.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -41,6 +41,6 @@ RedStone was designed with a modular architecture making it easy to incorporate
41
41
- Our code was audited by multiple security experts including [ABDK](https://abdk.consulting/)[Peckshield](https://peckshield.com/) and a co-founder of [L2Beat](https://pl.linkedin.com/company/l2beat#:~:text=Join%20Piotr%20Szlachciak%20Cofounder%20%26%20CEO,insights%20shaping%20the%20%23DeFi%20landscape!).
42
42
- RedStone supports leading projects like [Morpho](https://morpho.org/), [Venus](https://venus.io/), and [Pendle Finance](https://www.pendle.finance/).
Copy file name to clipboardExpand all lines: docs/data-providers/deploy.md
+15-17Lines changed: 15 additions & 17 deletions
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ sidebar_label: "Deploy"
5
5
6
6
# Deploy
7
7
8
-
In this section you will see how to run a RedStone node using Docker Compose.
8
+
In this section you will see how to run a RedStone node using Docker Compose.
9
9
10
10
:::caution
11
11
For production deployments consider using more sofisticated tools, e.g. Kubernetes.
@@ -18,11 +18,10 @@ For production deployments consider using more sofisticated tools, e.g. Kubernet
18
18
- At least 30 GB of storage (mainly for logs)
19
19
-[Docker](https://docs.docker.com/get-docker/) and [Docker Compose](https://docs.docker.com/compose/install/)
20
20
21
-
:::tip
21
+
:::tip
22
22
The hardware requirements for running a RedStone node are quite low, but you should reserve a healthy margin. The more resources you spare when provisioning your machine, the better it will perform and the less likely it will be to run into issues.
23
23
:::
24
24
25
-
26
25
### Docker Compose Example
27
26
28
27
Here's a simple example of a `docker-compose.yml` file that you can use to run the RedStone oracle node locally. Copy this configuration and adjust it to your needs.
internal: true # This ensures the network is private
71
+
internal: true # This ensures the network is private
73
72
```
74
73
75
74
### Services
76
75
77
76
#### RedsStone KMS (Key Management Service)
78
77
79
-
RedStone KMS' sole purpose is to handle all operations on your private key. It signs the data fetched by the oracle node and returns the evm address. This should be the only service that has access to your private key. Use the [RedStone KMS](https://gallery.ecr.aws/y7v2w8b2/kms) Docker image.
78
+
RedStone KMS' sole purpose is to handle all operations on your private key. It signs the data fetched by the oracle node and returns the evm address. This should be the only service that has access to your private key. Use the [RedStone KMS](https://gallery.ecr.aws/y7v2w8b2/kms) Docker image.
| **KMS_PRIVATE_KEY_FILE** | Path to the file with your private key. The file should contain a single line with your private key. | `KMS_PRIVATE_KEY_FILE=/run/secrets/private_key` |
84
83
| **KMS_PRIVATE_KEY** | Hex encoded key. Alternative way of passing the key | `KMS_PRIVATE_KEY=0xYOUR_PRIVATE_KEY` |
RedStone oracle node will fetch data from main public APIs, sign them with your private keys and broadcast to the streamr network and redstone Data Distribution Layer (DDL).
89
-
It should be configured using environment variables.
86
+
#### RedStone Node
90
87
88
+
RedStone oracle node will fetch data from main public APIs, sign them with your private keys and broadcast to the streamr network and redstone Data Distribution Layer (DDL).
89
+
It should be configured using environment variables.
| **ENABLE_REMOTE_SIGNER** | Delegate signing to a remote signer. Only this image has access to your ECDSA private key | `ENABLE_REMOTE_SIGNER=true` |
95
-
| REMOTE_SIGNER_URL | This is where Redstone's signer is listening. We recommend using a colocation e.g. in Kubernetes oracle-node and signer should be run in the same POD. By default `http://localhost:4499`.key | `REMOTE_SIGNER_URL=http://localhost:4499` |
| **ENABLE_REMOTE_SIGNER** | Delegate signing to a remote signer. Only this image has access to your ECDSA private key | `ENABLE_REMOTE_SIGNER=true` |
94
+
| REMOTE_SIGNER_URL | This is where Redstone's signer is listening. We recommend using a colocation e.g. in Kubernetes oracle-node and signer should be run in the same POD. By default `http://localhost:4499`.key | `REMOTE_SIGNER_URL=http://localhost:4499` |
96
95
| **OVERRIDE_DIRECT_CACHE_SERVICE_URLS** | Your personal private URLs of gateways to the RedStone Data Distribution Layer (DDL). For running a local node you can simply put `OVERRIDE_DIRECT_CACHE_SERVICE_URLS=["https://httpbin.org/anything"]`. But for production node running you should [request them](https://redstone.finance/discord) from the RedStone team. | `OVERRIDE_DIRECT_CACHE_SERVICE_URLS=["https://xxx.yyy.secret-url-1.com","https://zzz.aaa.secret-url-2.com"]` |
97
96
| **OVERRIDE_MANIFEST_USING_FILE** | Path to your manifest file. Manifest is a public JSON file that defines the provider's obligation regarding the data that they provide. It sets fetching interval, tokens, sources and other public technical details for the provided data. You can check available manifests [here.](https://github.com/redstone-finance/redstone-oracles-monorepo/tree/main/packages/oracle-node/manifests) | `OVERRIDE_MANIFEST_USING_FILE=./manifests/dev/dev.json` |
98
-
| **LEVEL_DB_LOCATION** | Path to the level DB. Each RedStone oracle node relies on a single-level DB. It is used to store recently fetched values from the last 15 minutes. These values are used for checking value deviations, filtering outliers and preventing price manipulation attacks. <br/><br/> You don't need to create a Level DB instance manually, it will be created automatically at the specified path during the first node launch. | `LEVEL_DB_LOCATION=/oracle-node-level-db` |
97
+
| **LEVEL_DB_LOCATION** | Path to the level DB. Each RedStone oracle node relies on a single-level DB. It is used to store recently fetched values from the last 15 minutes. These values are used for checking value deviations, filtering outliers and preventing price manipulation attacks. <br/><br/> You don't need to create a Level DB instance manually, it will be created automatically at the specified path during the first node launch. | `LEVEL_DB_LOCATION=/oracle-node-level-db` |
99
98
| **ENABLE_REMOTE_SIGNER** | Switch on signing with RedStone KMS | `ENABLE_REMOTE_SIGNER=true` |
100
99
101
100
:::tip Custom local manifest
102
101
If you want to run oracle-node from Docker with your custom manifest you should [mount the manifest file](https://docs.docker.com/storage/bind-mounts/) from your local system to the docker container and update the `OVERRIDE_MANIFEST_USING_FILE` env variable.
Copy file name to clipboardExpand all lines: docs/data-providers/introduction.md
+7-4Lines changed: 7 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -2,29 +2,32 @@
2
2
sidebar_position: 1
3
3
sidebar_label: "Introduction"
4
4
---
5
+
5
6
# Introduction
6
7
7
8
RedStone is one of the leading oracle providers on the market, but with great power comes great responsibility. In order to minimize the (already small) risk of price manipulation RedStone is allowing other, verified and trusted companies to send oracle data to its gateways. This way we increase safety, transparency and improve data quality.
8
9
9
-
We call those companies **External Oracle Providers** (EOP).
10
-
10
+
We call those companies **External Oracle Providers** (EOP).
11
11
12
12
## Becoming External Oracle Provider
13
13
14
14
Not every company may become an External Oracle Provider (EOP). Institutions need to meet some legal and technical conditions. The whole process may be divided into 3 steps - legal analysis, joining staging and joining production environments.
15
15
16
-
### Legal Analysis
16
+
### Legal Analysis
17
+
17
18
At the end of this stage EOP understands what are the legal consequences of malicious manipulation of rates. EOP also knows how the compensation mechanism works.
18
19
19
20
### Staging
21
+
20
22
Now that all legal matters are out of the way EOP will start setting up its own Oracle Node. At this point RedStone’s and EOP’s dev ops contact and set it all up.
21
23
First EOP connects to staging environment where we monitor in detail how stable is the deployment. We record downtime as well as the provided prices - we do everything we can to catch problems before EOP is moved to production.
22
24
23
25
This stage lasts for as long as it is needed, at least 30 days. RedStone will be in constant contact with EOP's team to inform about the problems so they may be fixed right away.
24
26
25
27
### Production
28
+
26
29
After EOP runs on Staging and both parties agree that it's ok - we move to Production. RedStone continues to monitor EOP, but now data is available in our production gateways.
27
30
28
31
:::info Data availability
29
32
RedStone consumers will be able to use the data published by your node [on all supported chains.](/docs/get-started/supported-chains) You can learn more about the RedStone Oracles architecture [here.](../get-started/selecting-redstone-model.md)
### How Data Is Unpacked, Verified and Then Aggregated On-Chain
43
47
44
48
Firstly, the appended data packages are extracted from the call data. Then, security steps are taken including verifying if the signature was created by a trusted provider and validating the timestamp, confirming the information is correct. Afterward, for each requested data feed RedStone calculates the number of received unique signers, extracts the value for each unique signer, and calculates the aggregated value. The middle value of all the values (median), is the default value that is provided. This logic is executed in the on-chain environment and its execution has been optimized using a low-level assembly code to reduce gas consumption to the absolute minimum. To increase the security of the RedStone Oracle system, we've created the on-chain aggregation mechanism. This mechanism adds an additional requirement of ensuring a minimum number of distinct data feeds are relied on. The values from different providers are then aggregated before returning to a consumer contract. By default, RedStone uses the median value calculation for aggregation. This way, even if a small subset of providers are corrupt (e.g. 2 of 10), it does not significantly affect the aggregated value.
0 commit comments