From 7f1b738b9f0ce865caffb10c5457dd971e8a1f05 Mon Sep 17 00:00:00 2001 From: thedriftofwords Date: Thu, 14 Mar 2024 14:16:52 -0400 Subject: [PATCH 1/2] Sentence case; move one CCIP page in nav --- src/config/sidebar.ts | 8 ++--- .../architecture-decentralized-model.mdx | 4 +-- .../architecture-overview.mdx | 6 ++-- .../architecture-request-model.mdx | 4 +-- src/content/ccip/architecture.mdx | 8 ++--- .../ccip/concepts/manual-execution.mdx | 6 ++-- .../concepts/best-practice.mdx | 2 +- .../guides/compatible-contracts.mdx | 2 +- .../guides/flexible-upkeeps.mdx | 2 +- .../chainlink-automation/guides/forwarder.mdx | 2 +- .../guides/job-scheduler.mdx | 12 +++---- .../guides/log-trigger.mdx | 14 ++++---- .../guides/manage-upkeeps.mdx | 4 +-- .../guides/register-upkeep.mdx | 10 +++--- .../overview/automation-economics.mdx | 2 +- .../api-reference/functions-request.mdx | 2 +- .../api-reference/javascript-source.mdx | 4 +-- .../resources/architecture.mdx | 12 +++---- .../chainlink-functions/resources/billing.mdx | 6 ++-- .../resources/subscriptions.mdx | 8 ++--- .../chainlink-nodes/contracts/operator.mdx | 4 +-- .../chainlink-nodes/contracts/ownership.mdx | 2 +- .../chainlink-nodes/contracts/receiver.mdx | 2 +- .../external-adapters/developers.mdx | 4 +-- src/content/chainlink-nodes/node-versions.mdx | 4 +-- .../resources/best-security-practices.mdx | 14 ++++---- .../connecting-to-a-remote-database.mdx | 4 +-- .../evm-performance-configuration.mdx | 4 +-- .../performing-system-maintenance.mdx | 4 +-- .../v1/fulfilling-requests.mdx | 4 +-- .../chainlink-nodes/v1/using-forwarder.mdx | 2 +- src/content/data-feeds/ens.mdx | 6 ++-- .../feed-registry/feed-registry-functions.mdx | 28 +++++++-------- .../data-feeds/feed-registry/index.mdx | 2 +- src/content/data-feeds/historical-data.mdx | 4 +-- src/content/data-feeds/solana/index.mdx | 2 +- src/content/data-feeds/using-data-feeds.mdx | 2 +- .../resources/contributing-to-chainlink.mdx | 22 ++++++------ src/content/resources/fund-your-contract.mdx | 2 +- src/content/resources/glossary.mdx | 24 ++++++------- .../resources/link-token-contracts.mdx | 34 +++++++++---------- .../v2/direct-funding/supported-networks.mdx | 2 +- .../v2/subscription/supported-networks.mdx | 2 +- 43 files changed, 148 insertions(+), 148 deletions(-) diff --git a/src/config/sidebar.ts b/src/config/sidebar.ts index fa16c6fc894..b958cfbb8e8 100644 --- a/src/config/sidebar.ts +++ b/src/config/sidebar.ts @@ -868,6 +868,10 @@ export const SIDEBAR: Partial> = { title: "Release Notes", url: "ccip/release-notes", }, + { + title: "Service Limits", + url: "ccip/service-limits", + }, ], }, { @@ -930,10 +934,6 @@ export const SIDEBAR: Partial> = { title: "Best Practices", url: "ccip/best-practices", }, - { - title: "Service Limits", - url: "ccip/service-limits", - }, ], }, { diff --git a/src/content/architecture-overview/architecture-decentralized-model.mdx b/src/content/architecture-overview/architecture-decentralized-model.mdx index 943323e9195..e87e8798089 100644 --- a/src/content/architecture-overview/architecture-decentralized-model.mdx +++ b/src/content/architecture-overview/architecture-decentralized-model.mdx @@ -17,7 +17,7 @@ import { ClickToZoom } from "@components" This page describes how data aggregation is applied to produce Chainlink Data Feeds and provides more insight as to how Data Feeds are updated. -## Data Aggregation +## Data aggregation Each data feed is updated by multiple, independent Chainlink oracle operators. The [AccessControlledOffchainAggregator](https://github.com/smartcontractkit/libocr/blob/master/contract/AccessControlledOffchainAggregator.sol) aggregates the data onchain. @@ -25,7 +25,7 @@ Offchain Reporting (OCR) further enhances the aggregation process. To learn more -## Shared Data Resource +## Shared data resource Each data feed is built and funded by the community of users who rely on accurate, up-to-date data in their smart contracts. As more users rely on and contribute to a data feed, the quality of the data feed improves. For this reason, each data feed has its own properties depending on the needs of its community of users. diff --git a/src/content/architecture-overview/architecture-overview.mdx b/src/content/architecture-overview/architecture-overview.mdx index 8db16505ef4..2c8b7257925 100644 --- a/src/content/architecture-overview/architecture-overview.mdx +++ b/src/content/architecture-overview/architecture-overview.mdx @@ -12,7 +12,7 @@ metadata: title: "Data Feeds Architecture" --- -## Basic Request Model +## Basic request model Chainlink connects smart contracts with external data using its decentralized oracle network. Chainlink API requests are handled 1:1 by an oracle. @@ -20,13 +20,13 @@ The [Basic Request Model](/architecture-overview/architecture-request-model) des To learn how to make a GET request using a single oracle, see [Make a GET Request](/any-api/get-request/introduction). -## Decentralized Data Model +## Decentralized data model For a more robust and trustworthy answer, you can aggregate data from many oracles. With onchain aggregation, data is aggregated from a decentralized network of independent oracle nodes. This architecture is applied to Chainlink Data Feeds, which can aggregate data such as asset price data. The [Decentralized Data Model](/architecture-overview/architecture-decentralized-model) describes how data is aggregated, and how consumer contracts can retrieve this data. -## Offchain Reporting +## Offchain reporting Offchain Reporting (OCR) is an improvement on the decentralization and scalability of Chainlink networks. With our Offchain Reporting aggregators, all nodes communicate using a peer to peer network. During the communication process, a lightweight consensus algorithm runs where each node reports its price observation and signs it. A single aggregate transaction is then transmitted, which saves a significant amount of gas. diff --git a/src/content/architecture-overview/architecture-request-model.mdx b/src/content/architecture-overview/architecture-request-model.mdx index 1e24846cd5a..77b4a17b3a2 100644 --- a/src/content/architecture-overview/architecture-request-model.mdx +++ b/src/content/architecture-overview/architecture-request-model.mdx @@ -14,7 +14,7 @@ metadata: import { ClickToZoom } from "@components" -## Contracts Overview +## Contracts overview All source code is open source and available in the [Chainlink Github repository](https://github.com/smartcontractkit/chainlink). @@ -54,7 +54,7 @@ Oracle contracts are responsible for handling onchain requests made through the For fulfillment, the oracle contract has a `fulfillOracleRequest` function which is used by the node to fulfill a request once it has the result of the job. This function returns the result to the `ChainlinkClient` using the callback function defined in the original request. -### Offchain Oracle Node +### Offchain oracle node The offchain oracle node is responsible for listening for events emitted by its corresponding onchain smart contract. Once it detects an `OracleRequest` event, it uses the data emitted to perform a job. diff --git a/src/content/ccip/architecture.mdx b/src/content/ccip/architecture.mdx index 8705c907cc7..77929412a6a 100644 --- a/src/content/ccip/architecture.mdx +++ b/src/content/ccip/architecture.mdx @@ -17,7 +17,7 @@ import { Aside, ClickToZoom } from "@components" page. -## High-Level Architecture +## High-level architecture Below is a diagram displaying the basic architecture of CCIP. Routers are smart contracts that provide a simple and consistent interface for users. Users can interact with routers to: @@ -45,7 +45,7 @@ CCIP enables a _sender_ on a _source blockchain_ to send a _message_ to a _recei | Receiver | A smart contract or an EOA. **Note**: An EOA cannot receive arbitrary data. It can only receive tokens. | | Destination Blockchain | The blockchain the receiver resides on. | -## Detailed Architecture +## Detailed architecture The figure below outlines the different components involved in a cross-chain transaction: @@ -112,7 +112,7 @@ Token pools provide rate limiting, which is a security feature enabling token is The Risk Management contract maintains the list of Risk Management node addresses that are allowed to bless or curse. The contract also holds the quorum logic for blessing a committed Merkle Root and cursing CCIP on a destination blockchain. Read the [Risk Management Network Concepts](/ccip/concepts#risk-management-network) section to learn more. -### Offchain Components +### Offchain components #### Committing DON @@ -164,7 +164,7 @@ Each [lane](/ccip/concepts#lane) also has an aggregate rate limit that limits th Consider an example where a lane has a maximum capacity of 100,000 USD, a refill rate of 167 USD per second, and several token transfers with a total value of 60,000 USD have been executed. In that example, the remaining available capacity is 40,000 USD. If a user intends to transfer tokens equating to 50,000 USD, they must wait at least 60 seconds for capacity to refill the additional 10,000 USD that is required. The maximum throughput in USD value on the lane is 100,000 USD every 10 minutes. -## CCIP Execution latency +## CCIP execution latency Chainlink CCIP has been purposely designed to take a security-first approach to minimize the risk of block reorgs on the source blockchain. The end-to-end transaction time of a CCIP cross-chain transaction largely depends on the time it takes for the transaction on the source chain to reach [finality](/ccip/concepts#finality). The time to reach finality varies by blockchain. For example, on Ethereum, it takes about [15 minutes for a block to be finalized](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/#finality). When cross-chain transactions are initiated from a chain with faster finality, such as Avalanche, which has a [time-to-finality of around one second](https://support.avax.network/en/articles/5325234-what-is-transactional-finality), the end-to-end transaction time is faster. diff --git a/src/content/ccip/concepts/manual-execution.mdx b/src/content/ccip/concepts/manual-execution.mdx index 8795a8efa60..dcdb38aeee1 100644 --- a/src/content/ccip/concepts/manual-execution.mdx +++ b/src/content/ccip/concepts/manual-execution.mdx @@ -64,7 +64,7 @@ Depending on the situation, you can take one of the following steps: When manual execution is initiated, a Merkle proof is generated for the message to be executed. During execution, the CCIP explorer submits the Merkle proof and the new gas limit (if the initial failure was due to a low gas limit). This Merkle proof is verified by the [OffRamp contract](/ccip/architecture#offramp) against the Merkle root in the [CommitStore contract](/ccip/architecture#commit-store), and that was blessed by the [Risk Management Network](/ccip/architecture#risk-management-network). This mirrors the automated execution performed by the [CCIP Executing DON](/ccip/architecture#executing-don), with the addition that the execution is resubmitted using the gas limit you provide. -## Frequently Asked Questions +## Frequently asked questions 1. **Can anyone execute a transaction on the CCIP explorer even if they are not the initiator of the transaction?** @@ -72,9 +72,9 @@ When manual execution is initiated, a Merkle proof is generated for the message
-1. **If a user sends multiple messages and the first message isn’t successfully delivered and goes into a _manual execution_ mode, does that mean all subsequent messages from the user will also be stuck?** +1. **If a user sends multiple messages and the first message isn't successfully delivered and goes into a _manual execution_ mode, does that mean all subsequent messages from the user will also be stuck?** - It depends. If a message goes into manual execution mode due to receiver errors (unhandled exceptions or gas limit issues), subsequent messages don’t get automatically blocked, unless they would encounter the same error. However, suppose a message goes into manual execution mode after the Smart Execution time window expires (currently 8 hours). In that case, subsequent messages must wait for the first message to be processed to maintain the default sequence. + It depends. If a message goes into manual execution mode due to receiver errors (unhandled exceptions or gas limit issues), subsequent messages don't get automatically blocked, unless they would encounter the same error. However, suppose a message goes into manual execution mode after the Smart Execution time window expires (currently 8 hours). In that case, subsequent messages must wait for the first message to be processed to maintain the default sequence.
diff --git a/src/content/chainlink-automation/concepts/best-practice.mdx b/src/content/chainlink-automation/concepts/best-practice.mdx index e8a48b9f75a..dd22e197597 100644 --- a/src/content/chainlink-automation/concepts/best-practice.mdx +++ b/src/content/chainlink-automation/concepts/best-practice.mdx @@ -34,7 +34,7 @@ As with all smart contract testing, it is important to test the boundaries of yo Test all of your mission-critical contracts, and stress-test the contract to confirm the performance and correct operation of your use case under load and adversarial conditions. The Chainlink Automation Network will continue to operate under stress, but so should your contract. For a list of supported testnet blockchains, please review the [supported networks page](/chainlink-automation/overview/supported-networks). -### Using ERC-677 Tokens +### Using ERC-677 tokens For registration on Mainnet, you need ERC-677 LINK. Many token bridges give you ERC-20 LINK tokens. Use PegSwap to [convert Chainlink tokens (LINK) to be ERC-677 compatible](https://pegswap.chain.link/). To register on a supported testnet, get [LINK](/resources/link-token-contracts) for the testnet that you want to use from our faucet. diff --git a/src/content/chainlink-automation/guides/compatible-contracts.mdx b/src/content/chainlink-automation/guides/compatible-contracts.mdx index 745a4cac794..b2c3c21bf1a 100644 --- a/src/content/chainlink-automation/guides/compatible-contracts.mdx +++ b/src/content/chainlink-automation/guides/compatible-contracts.mdx @@ -22,7 +22,7 @@ Before you deploy contracts to use with Chainlink Automation, read the [Best Pra -## Automation Compatible Contracts +## Automation compatible contracts A contract is Automation-compatible when it follows a specified interface that allows the Chainlink Automation Network to determine if, when, and how the contract should be automated. diff --git a/src/content/chainlink-automation/guides/flexible-upkeeps.mdx b/src/content/chainlink-automation/guides/flexible-upkeeps.mdx index e1120727cfa..23879d64357 100644 --- a/src/content/chainlink-automation/guides/flexible-upkeeps.mdx +++ b/src/content/chainlink-automation/guides/flexible-upkeeps.mdx @@ -117,4 +117,4 @@ In this example the total gas used by each `performUpkeep()` function was 133,46 ## Conclusion -Using Chainlink Automation efficiently not only allows you to reduce the gas fees, but also keeps them within predictable limits. That’s the reason why [several Defi protocols](https://chainlinktoday.com/prominent-founders-examine-chainlink-keepers-role-in-defis-evolution/) outsource their maintenance tasks to Chainlink Automation. +Using Chainlink Automation efficiently not only allows you to reduce the gas fees, but also keeps them within predictable limits. That's the reason why [several Defi protocols](https://chainlinktoday.com/prominent-founders-examine-chainlink-keepers-role-in-defis-evolution/) outsource their maintenance tasks to Chainlink Automation. diff --git a/src/content/chainlink-automation/guides/forwarder.mdx b/src/content/chainlink-automation/guides/forwarder.mdx index cc8d04b3225..0ddfc7f21b7 100644 --- a/src/content/chainlink-automation/guides/forwarder.mdx +++ b/src/content/chainlink-automation/guides/forwarder.mdx @@ -30,7 +30,7 @@ To make this work you will need to: - Create `setForwarder` function so you can update the `forwarder` address - After registration run `setForwarder` with the forwarder address in your UI, or programmatically fetch it using `registry.getForwarder(upkeepID)` using the Registry interface. -## Code Example +## Code example The code sample below uses the Forwarder: diff --git a/src/content/chainlink-automation/guides/job-scheduler.mdx b/src/content/chainlink-automation/guides/job-scheduler.mdx index aa8b21289fc..58be6536850 100644 --- a/src/content/chainlink-automation/guides/job-scheduler.mdx +++ b/src/content/chainlink-automation/guides/job-scheduler.mdx @@ -28,25 +28,25 @@ In the [Chainlink Automation App](https://automation.chain.link/), click the blu -### Connecting your Wallet +### Connecting your wallet If you do not already have a wallet connected with the Chainlink Automation network, the interface will prompt you to do so. Click the **Connect Wallet** button and follow the remaining prompts to connect your wallet to one of the [Automation supported blockchain networks](/chainlink-automation/overview/supported-networks). -## Trigger Selection +## Trigger selection Select **Time-based** trigger. -## Using Time-Based Triggers +## Using time-based triggers When you select the time-based trigger, you are prompted to enter a _contract address_. Provide the address of the contract you want to automate. If you did not verify the contract on chain, you will need to paste the [Application Binary Interface](https://docs.soliditylang.org/en/develop/abi-spec.html) (ABI) of the deployed contract into the corresponding text box. Select the function name that you want to execute and provide any static inputs. If you want to use dynamic inputs please see [Custom logic Upkeeps](/chainlink-automation/guides/register-upkeep) -### Specifying the Time Schedule +### Specifying the time schedule After you have successfully entered your contract address and ABI, specify your time schedule in the form of a [CRON expression](https://en.wikipedia.org/wiki/Cron). CRON expressions provide a shorthand way of creating a time schedule. You can use the provided example buttons in the Automation app to experiment with different schedules. Then, create your own time schedule. @@ -80,7 +80,7 @@ After entering your CRON expression, click **Next**. -## Entering Upkeep Details +## Entering upkeep details Provide the following information in the Automation app: @@ -107,7 +107,7 @@ Provide the following information in the Automation app: -## Complete Upkeep Registration +## Complete upkeep registration Click **Register upkeep** and confirm the transaction in MetaMask. ![Upkeep Registration Success Message](/images/automation/automation-registration-submitted.png) diff --git a/src/content/chainlink-automation/guides/log-trigger.mdx b/src/content/chainlink-automation/guides/log-trigger.mdx index 7d42c9aa1dc..7b054894781 100644 --- a/src/content/chainlink-automation/guides/log-trigger.mdx +++ b/src/content/chainlink-automation/guides/log-trigger.mdx @@ -20,7 +20,7 @@ Create powerful smart contracts that use log data as both trigger and input. Thi your upkeep on a testnet before deploying it to a mainnet. -## Emit a Log +## Emit a log 1. Open `CountEmitLog.sol` in Remix. This contract contains an event `WantsToCount` that keeps track of the address of the message sender. The function `emitCountLog` emits this event. @@ -60,19 +60,19 @@ Create powerful smart contracts that use log data as both trigger and input. Thi -### Connecting your Wallet +### Connecting your wallet If you do not already have a wallet connected with the Chainlink Automation network, the interface will prompt you to do so. Click the **Connect Wallet** button and follow the remaining prompts to connect your wallet to one of the [Automation supported blockchain networks](/chainlink-automation/overview/supported-networks). -## Trigger Selection +## Trigger selection Select **Log Trigger**. -## Using Log Triggers +## Using log triggers -## API Reference +## API reference ### Methods diff --git a/src/content/chainlink-nodes/external-adapters/developers.mdx b/src/content/chainlink-nodes/external-adapters/developers.mdx index b63751acea0..91d24559962 100644 --- a/src/content/chainlink-nodes/external-adapters/developers.mdx +++ b/src/content/chainlink-nodes/external-adapters/developers.mdx @@ -62,7 +62,7 @@ The values for `:parent` and `:child` can be used within the adapter to dynamica https://example.com/api/?parent=myParentValue&child=myChildValue ``` -### Returning Data +### Returning data When the external adapter wants to return data immediately, it must include `data` in the returned JSON. @@ -81,7 +81,7 @@ An example of the response data can look like: } ``` -### Returning Errors +### Returning errors If the endpoint gave a known error, the `error` field should be included in the external adapter's response back to the Chainlink node. diff --git a/src/content/chainlink-nodes/node-versions.mdx b/src/content/chainlink-nodes/node-versions.mdx index 09344a1629c..1ed744c1c4b 100644 --- a/src/content/chainlink-nodes/node-versions.mdx +++ b/src/content/chainlink-nodes/node-versions.mdx @@ -139,7 +139,7 @@ You can find a list of release notes for Chainlink nodes in the [smartcontractki - Corrected Ethereum Sepolia `LinkContractAddress` to `0x779877A7B0D9E8603169DdbD7836e478b4624789` - Fixed a bug that caused the Telemetry Manager to report incorrect health -### Upcoming Required Configuration Changes +### Upcoming required configuration changes Starting in `v2.9.0`: @@ -191,7 +191,7 @@ Starting in `v2.9.0`: - `P2P.V1` is now disabled (`Enabled = false`) by default. It must be explicitly enabled with `true` to be used. However, it is deprecated and will be removed in the future. - `P2P.V2` is now enabled (`Enabled = true`) by default. -### Upcoming Required Configuration Changes +### Upcoming required configuration changes Starting in `v2.9.0`: diff --git a/src/content/chainlink-nodes/resources/best-security-practices.mdx b/src/content/chainlink-nodes/resources/best-security-practices.mdx index 6472dc08b23..b52f3a9f391 100644 --- a/src/content/chainlink-nodes/resources/best-security-practices.mdx +++ b/src/content/chainlink-nodes/resources/best-security-practices.mdx @@ -6,7 +6,7 @@ title: "Security and Operation Best Practices" The following information provides a set of security and operation best practices that node operators need to use at a minimum to enhance the security and reliability of their infrastructure. -## Restricting Access +## Restricting access To run a Chainlink node, the Operator UI port does not need to be open on the internet for it to correctly function. Due to this, we strongly recommend restricting access to all of the services required over the internet. @@ -21,11 +21,11 @@ To run a Chainlink node, the Operator UI port does not need to be open on the in - With the use of the VPN, all traffic between Chainlink nodes and Ethereum clients is routed internally rather than over the internet. For example, all servers are placed in an internal subnet range such as `10.0.0.0/16` and use these IP addresses for communicating. - Chainlink nodes have the potential to send arbitrary HTTP GET and POST requests, exposing internal network resources. We recommend deploying with a DMZ which has strong outbound network restrictions. -## Failover Capabilities +## Failover capabilities To ensure there is very minimal downtime, failover capabilities are required on both the Chainlink and Ethereum clients so that if any one server fails, the service is still online. -**Minimum Requirements:** +**Minimum requirements:** - Chainlink nodes are using a PostgreSQL database that are not on the same servers as the Chainlink nodes. - At least two Chainlink nodes are running at any one time, with both of them pointing to the same database to ensure failover if one fails. @@ -36,7 +36,7 @@ To ensure there is very minimal downtime, failover capabilities are required on - If a VPN and internal routing is configured, SSL is not needed but still recommended, as all traffic is purely internal. - If both Ethereum and Chainlink nodes are public facing without a VPN, SSL is required to ensure that no communication between both can be intercepted. -## Disaster Recovery +## Disaster recovery Problems occur and when they do, the right processes need to be in-place to ensure that as little downtime as possible occurs. The main impediment to incurring large amounts of downtime in the context of Chainlink node operators is a fully corrupted Ethereum node that requires a re-sync. @@ -47,7 +47,7 @@ Due to the challenge of recovering an Ethereum client, we recommend: With this process in-place, the elapsed time of full disaster is kept to a minimum. -## Active Monitoring +## Active monitoring To be proactive in detecting any issues before or when they occur, active monitoring needs to be in place. The areas where we recommend to monitor are: @@ -60,13 +60,13 @@ To be proactive in detecting any issues before or when they occur, active monito Monitoring can be set up from the Docker container's output and fed into most major logging providers. For example, you can use Docker's docs to set up the logging driver for [Amazon CloudWatch](https://docs.docker.com/config/containers/logging/awslogs/) and [Google Cloud Logging](https://docs.docker.com/config/containers/logging/gcplogs/). You will want to set the [ JSON_CONSOLE](/chainlink-nodes/v1/configuration) configuration variable to `true` so that the output of the container is JSON-formatted for logging. -## Frequent Updates +## Frequent updates Due to the early nature of the software, it may be required to perform frequent updates to your Chainlink node. On performing system maintenance to update the Chainlink node, follow [this](/chainlink-nodes/resources/performing-system-maintenance/#failover-node-example) guide. -## Jobs and Config +## Jobs and config The following are suggestions for job specifications and configuration settings for the node. diff --git a/src/content/chainlink-nodes/resources/connecting-to-a-remote-database.mdx b/src/content/chainlink-nodes/resources/connecting-to-a-remote-database.mdx index 6958e38693a..fa725c4b228 100644 --- a/src/content/chainlink-nodes/resources/connecting-to-a-remote-database.mdx +++ b/src/content/chainlink-nodes/resources/connecting-to-a-remote-database.mdx @@ -12,7 +12,7 @@ This guide show you how to set up a PostgreSQL database and connect your Chainli - [Docker](https://docs.docker.com/samples/library/postgres/) - [Google Cloud](https://cloud.google.com/community/tutorials/setting-up-postgres) -## Obtain Information About Your Database +## Obtain information about your database In order to connect to a remote database, you must obtain information about the database and the server. Note the following database details so you can use them to configure your Chainlink node later: @@ -24,7 +24,7 @@ In order to connect to a remote database, you must obtain information about the The user must be the owner of the desired database. On first run, the migrations will create the tables necessary for the Chainlink node. -## Set Your DATABASE_URL Environment Variable +## Set Your DATABASE_URL environment variable Below is an example for setting the `DATABASE_URL` environment variable for your Chainlink Node's `.env` configuration file: diff --git a/src/content/chainlink-nodes/resources/evm-performance-configuration.mdx b/src/content/chainlink-nodes/resources/evm-performance-configuration.mdx index b7959c5dfca..486567c847c 100644 --- a/src/content/chainlink-nodes/resources/evm-performance-configuration.mdx +++ b/src/content/chainlink-nodes/resources/evm-performance-configuration.mdx @@ -90,7 +90,7 @@ Send-only nodes are used for broadcasting transactions only, and must support th ## Automatic load balancing and failover -Chainlink node version 1.3.0 and above has built in failover and load balancing for primary nodes. Chainlink always uses round-robin requests across all primary nodes. Chainlink monitors when nodes go offline and stops routing requests to those nodes. If you don’t want to use Chainlink’s built-in failover, or you want to use an external proxy instead, you can disable failover completely using the following environment variables: +Chainlink node version 1.3.0 and above has built in failover and load balancing for primary nodes. Chainlink always uses round-robin requests across all primary nodes. Chainlink monitors when nodes go offline and stops routing requests to those nodes. If you don't want to use Chainlink's built-in failover, or you want to use an external proxy instead, you can disable failover completely using the following environment variables: ```text NODE_NO_NEW_HEADS_THRESHOLD=0 @@ -216,7 +216,7 @@ Arbitrum Nitro runs a fork of go-ethereum internally, but the original flags are ## Adjusting minimum outgoing confirmations for high throughput jobs -`ethtx` tasks have a `minConfirmations` label that can be adjusted. You can get a minor performance boost if you set this label to `0`. Use this if you do not need to wait for confirmations on your `ethtx` tasks. For example, if you don't need the receipt or don’t care about failing the task if the transaction reverts onchain, you can set `minConfirmations` to `0`. +`ethtx` tasks have a `minConfirmations` label that can be adjusted. You can get a minor performance boost if you set this label to `0`. Use this if you do not need to wait for confirmations on your `ethtx` tasks. For example, if you don't need the receipt or don't care about failing the task if the transaction reverts onchain, you can set `minConfirmations` to `0`. Set the task label similarly to the following example: diff --git a/src/content/chainlink-nodes/resources/performing-system-maintenance.mdx b/src/content/chainlink-nodes/resources/performing-system-maintenance.mdx index 7d453139bb4..9d57ddf21d0 100644 --- a/src/content/chainlink-nodes/resources/performing-system-maintenance.mdx +++ b/src/content/chainlink-nodes/resources/performing-system-maintenance.mdx @@ -10,7 +10,7 @@ import { Tabs } from "@components/Tabs" You might occasionally need to restart the system that the Chainlink node runs on. To restart without any downtime for completing requests, perform the upgrade as a series of steps that passes database access to a new instance while the first instance is down. -## Maintenance and Image Update Example +## Maintenance and image update example