From 80f8d62c5ae1d21cffff6696c4a3be1480f561e7 Mon Sep 17 00:00:00 2001 From: biancabuzea200 Date: Wed, 4 Oct 2023 17:30:03 +0200 Subject: [PATCH 1/5] move network guides under Networks --- docs/networks/network/_category_.yml | 3 + .../network/switch-consensus-clients.md | 208 ++++++++ docs/networks/network/update-the-node.md | 478 ++++++++++++++++++ 3 files changed, 689 insertions(+) create mode 100644 docs/networks/network/_category_.yml create mode 100644 docs/networks/network/switch-consensus-clients.md create mode 100644 docs/networks/network/update-the-node.md diff --git a/docs/networks/network/_category_.yml b/docs/networks/network/_category_.yml new file mode 100644 index 0000000000..e58797b66e --- /dev/null +++ b/docs/networks/network/_category_.yml @@ -0,0 +1,3 @@ +label: '⛓️ Network Guides' +collapsed: true +position: 3 diff --git a/docs/networks/network/switch-consensus-clients.md b/docs/networks/network/switch-consensus-clients.md new file mode 100644 index 0000000000..22dd598fc5 --- /dev/null +++ b/docs/networks/network/switch-consensus-clients.md @@ -0,0 +1,208 @@ +--- +sidebar_label: 'Switch Consensus Clients' +sidebar_position: 2 +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +# Switching Consensus Clients + +Having a variety of clients in a blockchain network and improving our client diversity is critically important. + +Client diversity refers to utilizing different software clients in a blockchain network developed by various teams and in other programming languages. + +- **Security and Resilience**: Client diversity increases the robustness of the network. If there's a bug in one client, it doesn't bring down the entire network because other clients can continue to operate. This decentralization and redundancy is a fundamental aspect of blockchain security and resilience. +- **Decentralization and Governance**: Client diversity promotes decentralization in the development and governance of the Ethereum network. It prevents any team or entity from having too much influence over the network's growth. + +:::info + +Most validator nodes on the LUKSO mainnet are running with Geth and Prysm. Node operators are responsible to ensure they split their client usage evenly to the extent of officially supported clients and validators. + +::: + +## Switching from Prysm to Lighthouse + +:::caution Validator Keys + +As a validator, you need to import your validator deposit key files (`keystore-xxx-[timestamp].json`) that you have generated using the [LUKSO Wagyu](https://github.com/lukso-network/tools-wagyu-key-gen) or [LUKSO CLI Keygen](https://github.com/lukso-network/tools-key-gen-cli) tools. Ensure you safely copy them to your node before switching to a new consensus client. + +::: + +#### Stop your Node + +If you are currently running the Prysm consensus client, stop the clients before making any adjustments. + +:::caution + +If you configured custom services on top of the LUKSO CLI, please use your service commands to stop your node. + +::: + +:::tip + +The name of the directory `myLUKSOnode/` can be changed in the examples below. + +::: + +Move into your node's working directory. + +```bash +$ cd myLUKSOnode +``` + +Make sure to stop all processes of the blockchain node. + +```bash +$ lukso stop +``` + +Afterward, you can check if your node stopped correctly. + +```bash +$ lukso status +``` + +#### Create a new Working Directory + +Move out of your current node's working directory. + +```bash +$ cd .. +``` + +Next, create a new working directory for your updated node. Your old folder will act as a backup for your previous configuration and keystore files. + +```bash +$ mkdir myNewLUKSOnode && cd myNewLUKSOnode +``` + +#### Initialize the new Working Directory + +Next, you can initialize your new working folder. The command will download the latest network configurations and genesis files to synchronize with the LUKSO blockchain. + +```bash +$ lukso init +``` + +#### Install the Latest Clients + +After the initialization is successful, we must install the new blockchain clients. + +:::tip + +It is recommended to use Erigon and Lighthouse clients to address both client majorities at once. + +::: + +:::info + +After the installation has been successful, you can continue importing your validator keys into the new validator wallet that will be used within Lighthouse. You will be asked to set a new wallet password to safely store the imported deposit keys. Further, you must input your password for the deposit keys to be encrypted and added to the wallet. + +::: + +```bash +$ lukso install +``` + +#### Importing Validator Keys + +After the installation has been successful, you can continue importing your validator keys into the new validator wallet that will be used within Lighthouse. You will be asked to set a new wallet password to store the imported deposit keys safely. Further, you will have to input your password for the deposit keys, so that they can be encrypted and added to the wallet. + +```bash +$ lukso validator import --validator-keys "./path/to/your/keys/folder" +``` + +#### Checking Validator Keys + +After importing one or multiple folders, you can check your imported keys. + +```bash +$ lukso validator list +``` + +If the imported deposit keys match the ones in the original folder, you can delete them from your node machine. + +#### Start your new Node + +You can start your node as regular. If you run your node as a validator, please adjust your flags or the recipient address. + +:::info + +In case you did any modifications to your configuration files, such as: + +- configuring a Dynamic DNS +- connecting the blockchain explorer page +- adding a node name or graffiti +- adjusting your peer count + +Please add them again and ensure these are in the correct format before starting your node. + +::: + +:::caution + +Wait 10 minutes after stopping your node so the network does not accuse you of slashing while using updated configurations. + +::: + +Start up your node using checkpoint synchronization to reduce your downtime while synchronizing with the network significantly. Fast synchronization speeds are essential if you run a validator node to avoid losing stake. + +Your node will begin syncing from a recently finalized consensus checkpoint instead of genesis. It will then download the rest of the blockchain data while your consensus is already running. After the synchronization is finalized, you will end up with the equal blockchain data. + +> You can use the flag on every startup. However, it shows the most significant effect when synchronizing from scratch or after an extended downtime. + + + + +:::info + +If you are setting up a node for the testnet, add the `--testnet` flag to the start command. + +::: + +:::note + +You will need the LUKSO CLI Version 0.8.0 or above in order to use the `--checkpoint-sync` command. If you are using an older version, please pass down the checkpoint flag as described in the [LUKSO CLI Documentation](https://github.com/lukso-network/tools-lukso-cli/tree/main#using-checkpoint-syncing). + +::: + +```sh +# Starting the Mainnet Node +$ lukso start --checkpoint-sync + +# Starting the Mainnet Validator +$ lukso start --validator --transaction-fee-recipient "0x1234" --checkpoint-sync +``` + + + + +:::caution + +The normal synchronization process will take multiple hours for the node to finalize. It is not recommended if you are running a validator. + +::: + +:::info + +If you are setting up a node for the testnet, add the `--testnet` flag to the start command. + +::: + +```bash +# Starting the Mainnet Node +$ lukso start + +# Starting the Mainnet Validator +$ lukso start --validator --transaction-fee-recipient "0x1234" +``` + + + + +:::info + +After your node finalizes the synchronization with the network, you can remove the validator key folder and the old working directory. + +::: diff --git a/docs/networks/network/update-the-node.md b/docs/networks/network/update-the-node.md new file mode 100644 index 0000000000..a66df1adf9 --- /dev/null +++ b/docs/networks/network/update-the-node.md @@ -0,0 +1,478 @@ +--- +sidebar_label: 'Update the Node' +sidebar_position: 1 +--- + +import Tabs from '@theme/Tabs'; +import TabItem from '@theme/TabItem'; + +# Update the Node + +Updating your node and blockchain clients is of utmost importance. It is not just about having access to the latest features of the LUKSO CLI, but an essential aspect of maintaining your node's security, performance, and reliability, directly affecting the network. + +## Check your LUKSO CLI Version + +:::info Breaking Changes + +Since the mainnet launch occurred, the LUKSO CLI had breaking changes from version `0.6` to `0.7`. + +::: + +Please check your current LUKSO CLI version to determine your update process. + +```bash +$ lukso version +``` + +This guide will lead you through updating to **LUKSO CLI Version 0.8** + +## Update the LUKSO CLI + +Updating your node is similar to the installing process, while keeping your previous keystore data. If you already have the **latest LUKSO CLI version** and **network configs**, you can also just update your [blockchain clients](#updating-the-blockchain-clients). + + + + +#### Stop your Node + +:::caution + +If you configured custom services on top of the LUKSO CLI, please use your service commands to stop your node. + +::: + +:::tip + +The name of the directory `myLUKSOnode/` can be changed in the examples below. + +::: + +Move into your node's working directory. + +```bash +$ cd myLUKSOnode +``` + +Make sure to stop all processes of the blockchain node. + +```bash +$ lukso stop +``` + +Afterward, you can check if your node stopped correctly. + +```bash +$ lukso status +``` + +If you have problems stopping the processes, please use the `pkill` command to force their shutdowns. + +```bash +# Stop the Geth client +$ sudo pkill geth + +# Stop the Erigon client +$ sudo pkill erigon + +# Stop the Prysm client +$ sudo pkill prysm + +# Stop the Prysm Validator client +$ sudo pkill validator + +# Stop the Lighthouse and Lighthouse Validator clients +$ sudo pkill lighthouse +``` + +#### Create a new Working Directory + +Move out of your current node's working directory. + +```bash +$ cd .. +``` + +Next, create a new working directory for your updated node. Your old folder will act as a backup for your configuration and keystore files. + +```bash +$ mkdir myNewLUKSOnode && cd myNewLUKSOnode +``` + +#### Update the LUKSO CLI + +Re-install the LUKSO CLI to your system. You will be asked to overwrite the current version. + +```bash +$ curl https://install.lukso.network | sh +``` + +Make sure to check the downloaded version again, ensuring that the update was successful. + +```bash +$ lukso version +``` + +#### Initialize the new Working Directory + +Next, you can initialize your new working folder. The command will download the latest network configurations and genesis files to synchronize with the LUKSO blockchain. + +```bash +$ lukso init +``` + +#### Install the Latest Clients + +After the initialization is successful, we must install the updated blockchain clients. + +```bash +$ lukso install +``` + +#### Copy the Validator Keys + +In case you are running a validator, you are able to copy your keystore files to the new folder. The keystore data in your old folder will act as a backup. + +> Make sure to adjust the commands using the actual name of the previous folder instead of the placeholder. + +:::caution + +Only copy over your keystore data if you want to use the same consensus client as before the update. Otherwise, you would have to import your validator keys from scratch. + +::: + +```bash +# Copy Mainnet Node Data +$ cp -r ../myOldLUKSOnode/mainnet-keystore . + +# Copy Testnet Node Data +$ cp -r ../myOldLUKSOnode/testnet-keystore . +``` + +#### Restart your Node + +You can start your node as regular. Please adjust your flags or the recipient address in case you are running a validator. + +:::info + +In case you did any modifications to your configuration files, such as: + +- configuring a Dynamic DNS +- connecting the blockchain explorer page +- adding a node name or graffiti +- adjusting your peer count + +Please add them once again and make sure that these are in the correct format before starting your node. + +::: + +:::caution + +Wait 10 minutes after stopping your node so the network does not accuse you of slashing while using updated configurations. + +::: + +Start up your node using checkpoint synchronization to reduce your downtime while synchronizing with the network significantly. Fast synchronization speeds are essential if you run a validator node to avoid losing stake. + +Your node will begin syncing from a recently finalized consensus checkpoint instead of genesis. It will then download the rest of the blockchain data while your consensus is already running. After the synchronization is finalized, you will end up with the equal blockchain data. + +> You can use the flag on every startup. However, it shows the most significant effect when synchronizing from scratch or after an extended downtime. + + + + +:::info + +If you are setting up a node for the testnet, add the `--testnet` flag to the start command. + +::: + +```sh +# Starting the Mainnet Node +$ lukso start --checkpoint-sync + +# Starting the Mainnet Validator +$ lukso start --validator --transaction-fee-recipient "0x1234" --checkpoint-sync +``` + + + + +:::caution + +The normal synchronization process will take multiple hours for the node to finalize. It is not recommended if you are running a validator. + +::: + +:::info + +If you are setting up a node for the testnet, add the `--testnet` flag to the start command. + +::: + +```bash +# Starting the Mainnet Node +$ lukso start + +# Starting the Mainnet Validator +$ lukso start --validator --transaction-fee-recipient "0x1234" +``` + + + + +:::info + +After your node has finalized the synchronization with the network, you can remove the old working directory from your system. + +::: + + + + +#### Stop your Node + +:::caution + +If you configured custom services on top of the LUKSO CLI, please use your service commands to stop your node. + +::: + +Move into your node's working directory. + +```bash +$ cd myLUKSOnode +``` + +Make sure to stop all processes of the blockchain node. + +```bash +$ lukso stop +``` + +Afterward, you can check if your node stopped correctly. + +```bash +$ lukso status +``` + +#### Remove outdated Blockchain Data + +If the processes have been stopped successfully, you can continue to remove the old network data. + +```bash +# Remove Mainnet Data +$ rm -rf mainnet-data + +# Remove Testnet Data +$ rm -rf testnet-data +``` + +#### Backup outdated Configuration + +Next, you can rename your configuration folder to reload the latest network files later on. + +```bash +$ mv configs/ configs-backup +``` + +#### Update the LUKSO CLI + +Re-install the LUKSO CLI to your system. You will be asked to overwrite the current version. + +```bash +$ curl https://install.lukso.network | sh +``` + +Make sure to check the downloaded version again to ensure that the update was successful. + +```bash +$ lukso version +``` + +#### Re-initialize the Working Directory + +Next, you can re-download the latest network configurations and genesis files. + +```bash +$ lukso init +``` + +#### Install the Latest Clients + +After updating the LUKSO CLI, we must install the updated blockchain clients. + +```bash +$ lukso install +``` + +#### Restart your Node + +You can start your node as regular. If you run a validator, please adjust your flags or the recipient address. + +:::info + +In case you did any modifications to your configuration files, such as: + +- configuring a Dynamic DNS +- connecting the blockchain explorer page +- adding a node name or graffiti +- adjusting your peer count + +Please add them again and ensure these are in the correct format before starting your node. + +::: + +:::caution + +Wait 10 minutes after stopping your node so the network does not accuse you of slashing while using updated configurations. + +::: + +Start up your node using checkpoint synchronization to reduce your downtime while synchronizing with the network significantly. Fast synchronization speeds are essential if you run a validator node to avoid losing stake. + +Your node will begin syncing from a recently finalized consensus checkpoint instead of genesis. It will then download the rest of the blockchain data while your consensus is already running. After the synchronization is finalized, you will end up with the equal blockchain data. + +> You can use the flag on every startup. However, it shows the most significant effect when synchronizing from scratch or after an extended downtime. + + + + +:::info + +If you are setting up a node for the testnet, add the `--testnet` flag to the start command. + +::: + +```sh +# Starting the Mainnet Node +$ lukso start --checkpoint-sync + +# Starting the Mainnet Validator +$ lukso start --validator --transaction-fee-recipient "0x1234" --checkpoint-sync +``` + + + + +:::caution + +The normal synchronization process will take multiple hours for the node to finalize. It is not recommended if you are running a validator. + +::: + +:::info + +If you are setting up a node for the testnet, add the `--testnet` flag to the start command. + +::: + +```bash +# Starting the Mainnet Node +$ lukso start + +# Starting the Mainnet Validator +$ lukso start --validator --transaction-fee-recipient "0x1234" +``` + + + + +:::info + +After your node has finalized the synchronization with the network, you can remove the `configs-backup` folder from your system. + +::: + + + + +## Update the Blockchain Clients + +If you already use the **latest LUKSO CLI version** and **network configuration** but want to check for new blockchain client versions, you can update them separately. + +### Stop your Node + +:::caution + +If you configured custom services on top of the LUKSO CLI, please use your service commands to stop your node. + +::: + +Move into your node's working directory. + +```bash +$ cd myLUKSOnode +``` + +Stop all processes of the blockchain node. + +```bash +$ lukso stop +``` + +Afterward, you can check if your node stopped correctly. + +```bash +$ lukso status +``` + +### Download new Clients + +Then continue to check and update your configured blockchain clients. + +```bash +$ lukso update +``` + +#### Restart your Node + +You can start your node as regular. If you run a validator, please adjust your flags or the recipient address. + +Start up your node using checkpoint synchronization to reduce your downtime while synchronizing with the network significantly. Fast synchronization speeds are essential if you run a validator node to avoid losing stake. + +Your node will begin syncing from a recently finalized consensus checkpoint instead of genesis. It will then download the rest of the blockchain data while your consensus is already running. After the synchronization is finalized, you will end up with the equal blockchain data. + +> You can use the flag on every startup. However, it shows the most significant effect when synchronizing from scratch or after an extended downtime. + + + + +:::info + +If you are setting up a node for the testnet, add the `--testnet` flag to the start command. + +::: + +```sh +# Starting the Mainnet Node +$ lukso start --checkpoint-sync + +# Starting the Mainnet Validator +$ lukso start --validator --transaction-fee-recipient "0x1234" --checkpoint-sync +``` + + + + +:::caution + +The normal synchronization process will take multiple hours for the node to finalize. It is not recommended if you are running a validator. + +::: + +:::info + +If you are setting up a node for the testnet, add the `--testnet` flag to the start command. + +::: + +```bash +# Starting the Mainnet Node +$ lukso start + +# Starting the Mainnet Validator +$ lukso start --validator --transaction-fee-recipient "0x1234" +``` + + + From 08db9b42a964ce5e8cbb5ad855641475baadbe46 Mon Sep 17 00:00:00 2001 From: biancabuzea200 Date: Thu, 5 Oct 2023 10:57:14 +0200 Subject: [PATCH 2/5] remove lsp16UniversalFactory& delete note --- .../lsp16-universal-factory.md | 5 - docs/standards/rpc-api.md | 6 - docs/standards/smart-contracts/_category_.yml | 3 - .../lsp16-universal-factory.md | 262 ------------------ 4 files changed, 276 deletions(-) delete mode 100644 docs/standards/smart-contracts/_category_.yml delete mode 100644 docs/standards/smart-contracts/lsp16-universal-factory.md diff --git a/docs/standards/generic-standards/lsp16-universal-factory.md b/docs/standards/generic-standards/lsp16-universal-factory.md index 7adc587efe..4488e3aeaf 100644 --- a/docs/standards/generic-standards/lsp16-universal-factory.md +++ b/docs/standards/generic-standards/lsp16-universal-factory.md @@ -35,11 +35,6 @@ This multi-chain compatibility eliminates the **risk of asset loss** due to mism ### Specification -:::tip - -Check the [**LSP16UniversalFactory contract functions**](../../standards/smart-contracts/lsp16-universal-factory.md) to know how to deploy contracts at the same address across different chains. -::: - LSP16 establishes a range of functions to deploy different types of contracts using the [CREATE2](https://eips.ethereum.org/EIPS/eip-1014) opcode, including standard and initializable contracts (proxies). For initializable contracts, the initialization data is included into the salt to prevent address squatting across chains. diff --git a/docs/standards/rpc-api.md b/docs/standards/rpc-api.md index 5dc3d36d7e..4c8d301915 100644 --- a/docs/standards/rpc-api.md +++ b/docs/standards/rpc-api.md @@ -5,12 +5,6 @@ sidebar_position: 10 # 🆙 RPC API -:::danger Work in progress - -This page is under active development. - -::: - The [LUKSO UP Browser Extension](../guides/browser-extension/install-browser-extension.md) uses the RPC API methods from the table below. The methods are grouped by category: signing methods, standard methods, and LUKSO-specific methods. ## Supported Methods diff --git a/docs/standards/smart-contracts/_category_.yml b/docs/standards/smart-contracts/_category_.yml deleted file mode 100644 index 58bcf445f6..0000000000 --- a/docs/standards/smart-contracts/_category_.yml +++ /dev/null @@ -1,3 +0,0 @@ -label: '📑 Smart Contract ABI' -collapsed: true -position: 8 diff --git a/docs/standards/smart-contracts/lsp16-universal-factory.md b/docs/standards/smart-contracts/lsp16-universal-factory.md deleted file mode 100644 index a2dbe03d39..0000000000 --- a/docs/standards/smart-contracts/lsp16-universal-factory.md +++ /dev/null @@ -1,262 +0,0 @@ ---- -title: LSP16UniversalFactory -sidebar_position: 13 ---- - -# LSP16UniversalFactory - -:::info Solidity contract - -[`LSP16UniversalFactory.sol`](https://github.com/lukso-network/lsp-smart-contracts/blob/main/contracts/LSP16UniversalFactory/LSP16UniversalFactory.sol) - -::: - -The **LSP16UniversalFactory** contract is the official implementation of the **[LSP16-UniversalFactory Standard](../generic-standards//lsp16-universal-factory.md)**. - -This factory contract is designed to deploy contracts at the same address on multiple chains given specific requirements using [CREATE2](https://eips.ethereum.org/EIPS/eip-1014). The **UniversalFactory** can deploy 2 types of contracts: - -- non-initializable (normal deployment) -- initializable (external call after deployment, e.g: proxy contracts) - ---- - -## Requirements - -In order to reproduce the same addresses of the contract to be created from this factory, the factory itself needs to be deployed at the same address on any chain. - -[LSP16-UniversalFactory](../generic-standards/lsp16-universal-factory.md) standardize the address of the factory to be `0x160000700D62B8dDC65FaeD5AC5Add2d2e30A803`. - -Check the standard to know more how to deploy the factory at this address. - -## Functions - -### deployCreate2 - -```solidity -function deployCreate2(bytes calldata byteCode, bytes32 providedSalt) public payable returns (address) -``` - -Deploys a contract using the CREATE2 opcode. The address where the contract will be deployed can be known in advance via the [`computeAddress(..)`](#computeaddress) function. - -This function deploys contracts without initialization (external call after deployment). - -The `providedSalt` parameter is not used directly as the salt by the CREATE2 opcode. Instead, it is hashed with -keccak256: `keccak256(abi.encodePacked(false, providedSalt))`. See [`generateSalt(..)`](#generatesalt) function for more details. - -**Requirements:** - -- If value is associated with the contract creation, the constructor of the contract to deploy MUST be payable, otherwise the call will revert. - -- MUST NOT use the same bytecode and providedSalt twice, otherwise the call will revert. - -#### Parameters: - -| Name | Type | Description | -| :------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | -| `byteCode` | `bytes` | The bytecode of the contract to deploy (appended with constructor params if exist) | -| `providedSalt` | `bytes32` | The salt provided by the deployer, which will be used to generate the final salt that will be used by the `CREATE2` opcode for contract deployment | - -#### Return Values: - -| Name | Type | Description | -| :---------------- | :-------- | :----------------------------------- | -| `contractCreated` | `address` | The address of the contract created. | - -### deployCreate2AndInitialize - -```solidity -function deployCreate2AndInitialize(bytes calldata byteCode, bytes32 providedSalt, bytes calldata initializeCalldata, uint256 constructorMsgValue, uint256 initializeCalldataMsgValue) public payable returns (address) -``` - -Deploys a contract using the CREATE2 opcode. The address where the contract will be deployed can be known in advance via the [`computeAddress(..)`](#computeaddress) function. - -This function deploys contracts with initialization (external call after deployment). - -The `providedSalt` parameter is not used directly as the salt by the CREATE2 opcode. Instead, it is hashed with keccak256: `keccak256(abi.encodePacked(true, initializeCalldata, providedSalt))`. See [`generateSalt(..)`](#generatesalt) function for more details. - -**Requirements:** - -- If value is associated with the contract creation, the constructor of the contract to deploy MUST be payable, otherwise the call will revert. - -- If value is associated with the initialization call, the initialize function called on the contract to deploy MUST be payable, otherwise the call will revert. - -- The sum of `constructorMsgValue` and `initializeCalldataMsgValue` MUST be equal to the value associated with the function call. - -- MUST NOT use the same `bytecode` and `providedSalt` twice, otherwise the call will revert. - -#### Parameters: - -| Name | Type | Description | -| :--------------------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | -| `byteCode` | `bytes` | The bytecode of the contract to deploy (appended with constructor params if exist) | -| `providedSalt` | `bytes32` | The salt provided by the deployer, which will be used to generate the final salt that will be used by the `CREATE2` opcode for contract deployment | -| `initializeCalldata` | `bytes` | The calldata to be executed on the created contract | -| `constructorMsgValue` | `uint256` | The value sent to the contract during deploymentcontract | -| `initializeCalldataMsgValue` | `uint256` | The value sent to the contract during initialization | - -#### Return Values: - -| Name | Type | Description | -| :---------------- | :-------- | :----------------------------------- | -| `contractCreated` | `address` | The address of the contract created. | - -### deployERC1167Proxy - -```solidity -function deployERC1167Proxy(address implementationContract, bytes32 providedSalt) public virtual returns (address) -``` - -Deploys an ERC1167 minimal proxy contract using the CREATE2 opcode. The address where the contract will be deployed can be known in advance via the [`computeERC1167Address(..)`](#computeERC1167address) function. - -This function deploys contracts without initialization (external call after deployment). - -The `providedSalt` parameter is not used directly as the salt by the CREATE2 opcode. Instead, it is hashed with keccak256: `keccak256(abi.encodePacked(false, providedSalt))`. See [`generateSalt(..)`](#generatesalt) function for more details. See [`generateSalt(..)`](#generatesalt) function for more details. - -#### Parameters: - -| Name | Type | Description | -| :----------------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | -| `implementationContract` | `address` | The contract address to use as the base implementation behind the proxy that will be deployed | -| `providedSalt` | `bytes32` | The salt provided by the deployer, which will be used to generate the final salt that will be used by the `CREATE2` opcode for contract deployment | - -#### Return Values: - -| Name | Type | Description | -| :------ | :-------- | :---------------------------------------- | -| `proxy` | `address` | The address of the minimal proxy created. | - -### deployERC1167ProxyAndInitialize - -```solidity -function deployERC1167ProxyAndInitialize(address implementationContract, bytes32 providedSalt, bytes calldata initializeCalldata) public payable virtual returns (address) -``` - -Deploys an ERC1167 minimal proxy contract using the CREATE2 opcode. The address where the contract will be deployed can be known in advance via the [`computeERC1167Address(..)`](#computeERC1167address) function. - -This function deploys contracts with initialization (external call after deployment). - -The `providedSalt` parameter is not used directly as the salt by the CREATE2 opcode. Instead, it is hashed with keccak256: `keccak256(abi.encodePacked(true, initializeCalldata, providedSalt))`. See [`generateSalt(..)`](#generatesalt) function for more details. - -#### Parameters: - -| Name | Type | Description | -| :----------------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | -| `implementationContract` | `address` | The contract address to use as the base implementation behind the proxy that will be deployed | -| `providedSalt` | `bytes32` | The salt provided by the deployer, which will be used to generate the final salt that will be used by the `CREATE2` opcode for contract deployment | -| `initializeCalldata` | `bytes` | The calldata to be executed on the created contract | - -#### Return Values: - -| Name | Type | Description | -| :------ | :-------- | :---------------------------------------- | -| `proxy` | `address` | The address of the minimal proxy created. | - -### computeAddress - -```solidity -function computeAddress(bytes32 bytecodeHash, bytes32 providedSalt, bool initializable, bytes calldata initializeCalldata) public view virtual returns (address) -``` - -Computes the address of a contract to be deployed using CREATE2, based on the input parameters. Any change in one of these parameters will result in a different address. - -When the `initializable` boolean is set to `false`, `initializeCalldata` will not affect the function output. - -#### Parameters: - -| Name | Type | Description | -| :------------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | -| `byteCodeHash` | `bytes32` | The keccak256 hash of the bytecode to be deployed | -| `providedSalt` | `bytes32` | The salt provided by the deployer, which will be used to generate the final salt that will be used by the `CREATE2` opcode for contract deployment | -| `initializable` | `bool` | A boolean that indicates whether an external call should be made to initialize the contract after deployment | -| `initializeCalldata` | `bytes` | The calldata to be executed on the created contract if `initializable` is set to `true` | - -#### Return Values: - -| Name | Type | Description | -| :----------------- | :-------- | :----------------------------------------------- | -| `contractToCreate` | `address` | The address where the contract will be deployed. | - -### computeERC1167Address - -```solidity -function computeERC1167Address(address implementationContract, bytes32 providedSalt, bool initializable, bytes calldata initializeCalldata) public view virtual returns (address) -``` - -Computes the address of a contract to be deployed using CREATE2, based on the input parameters. Any change in one of these parameters will result in a different address. - -When the `initializable` boolean is set to `false`, `initializeCalldata` will not affect the function output. - -#### Parameters: - -| Name | Type | Description | -| :----------------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | -| `implementationContract` | `address` | The contract to create a clone of according to ERC1167 | -| `providedSalt` | `bytes32` | The salt provided by the deployer, which will be used to generate the final salt that will be used by the `CREATE2` opcode for contract deployment | -| `initializable` | `bool` | A boolean that indicates whether an external call should be made to initialize the contract after deployment | -| `initializeCalldata` | `bytes` | The calldata to be executed on the created contract if `initializable` is set to `true` | - -#### Return Values: - -| Name | Type | Description | -| :-------------- | :-------- | :----------------------------------------------- | -| `proxyToCreate` | `address` | The address where the contract will be deployed. | - -### generateSalt - -```solidity -function generateSalt(bytes32 providedSalt, bool initializable, bytes memory initializeCalldata) public view virtual returns (bytes32) -``` - -Generates the salt used to deploy the contract by hashing the following parameters (concatenated together) with keccak256: - -- the `providedSalt` -- the `initializable` boolean -- the `initializeCalldata`, only if the contract is initializable (the `initializable` boolean is set to `true`) - -This approach ensures that in order to reproduce an initializable contract at the same address on another chain, not only the `providedSalt` is required to be the same, but also the initialize parameters within the `initializeCalldata` must also be the same. - -This maintains consistent deployment behaviour. Users are required to initialize contracts with the same parameters across different chains to ensure contracts are deployed at the same address across different chains. - -#### Parameters: - -| Name | Type | Description | -| :------------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------- | -| `providedSalt` | `bytes32` | The salt provided by the deployer, which will be used to generate the final salt that will be used by the `CREATE2` opcode for contract deployment | -| `initializable` | `bool` | A boolean that indicates whether an external call should be made to initialize the contract after deployment | -| `initializeCalldata` | `bytes` | The calldata to be executed on the created contract if `initializable` is set to `true` | - -#### Return Values: - -| Name | Type | Description | -| :-------------- | :-------- | :----------------------------------------------------------- | -| `generatedSalt` | `address` | The generated salt which will be used for CREATE2 deployment | - -## Events - -### ContractCreated - -```solidity -event ContractCreated( - address indexed contractCreated, - bytes32 indexed providedSalt, - bytes32 generatedSalt, - bool indexed initialized, - bytes initializeCalldata -); -``` - -_**MUST** be fired when a contract is created successfully._ - -#### Values: - -| Name | Type | Description | -| :------------------- | :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------ | -| `contractCreated` | `address` | The address of the contract created | -| `providedSalt` | `bytes32` | The salt provided by the deployer which will be used to generate the final salt that will be used by the `CREATE2` opcode for contract deployment | -| `generatedSalt` | `bytes32` | The salt used by the `CREATE2` opcode for contract deployment | -| `initialized` | `bool` | The Boolean that specifies if the contract must be initialized or not | -| `initializeCalldata` | `bytes` | The bytes provided as initializeCalldata (Empty string when `initialized` is set to false) | - -## References - -- [Solidity implementations (GitHub)](https://github.com/lukso-network/lsp-universalprofile-smart-contracts/tree/develop/contracts) From 15d1ed5577e83b27cfff593e66d1fcfb06b125c6 Mon Sep 17 00:00:00 2001 From: biancabuzea200 Date: Thu, 5 Oct 2023 13:16:14 +0200 Subject: [PATCH 3/5] add redirect to the LSP16 ABI technical docs --- docs/standards/generic-standards/lsp16-universal-factory.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/standards/generic-standards/lsp16-universal-factory.md b/docs/standards/generic-standards/lsp16-universal-factory.md index 4488e3aeaf..681e4a57e2 100644 --- a/docs/standards/generic-standards/lsp16-universal-factory.md +++ b/docs/standards/generic-standards/lsp16-universal-factory.md @@ -35,6 +35,12 @@ This multi-chain compatibility eliminates the **risk of asset loss** due to mism ### Specification +:::tip + +Check the [**LSP16UniversalFactory contract functions**](../../contracts/contracts/LSP16UniversalFactory/LSP16UniversalFactory.md) to know how to deploy contracts at the same address across different chains. + +::: + LSP16 establishes a range of functions to deploy different types of contracts using the [CREATE2](https://eips.ethereum.org/EIPS/eip-1014) opcode, including standard and initializable contracts (proxies). For initializable contracts, the initialization data is included into the salt to prevent address squatting across chains. From f3db5e9ac7315b27e90a77d0f60c4ae6711f66a7 Mon Sep 17 00:00:00 2001 From: biancabuzea200 Date: Thu, 5 Oct 2023 14:40:12 +0200 Subject: [PATCH 4/5] remove duplicate guide& create redirects --- docs/guides/network/_category_.yml | 3 - .../network/switch-consensus-clients.md | 208 -------- docs/guides/network/update-the-node.md | 478 ------------------ docusaurus.config.js | 8 + 4 files changed, 8 insertions(+), 689 deletions(-) delete mode 100644 docs/guides/network/_category_.yml delete mode 100644 docs/guides/network/switch-consensus-clients.md delete mode 100644 docs/guides/network/update-the-node.md diff --git a/docs/guides/network/_category_.yml b/docs/guides/network/_category_.yml deleted file mode 100644 index e8e1644e46..0000000000 --- a/docs/guides/network/_category_.yml +++ /dev/null @@ -1,3 +0,0 @@ -label: '⛓️ Network' -collapsed: true -position: 1 diff --git a/docs/guides/network/switch-consensus-clients.md b/docs/guides/network/switch-consensus-clients.md deleted file mode 100644 index 22dd598fc5..0000000000 --- a/docs/guides/network/switch-consensus-clients.md +++ /dev/null @@ -1,208 +0,0 @@ ---- -sidebar_label: 'Switch Consensus Clients' -sidebar_position: 2 ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -# Switching Consensus Clients - -Having a variety of clients in a blockchain network and improving our client diversity is critically important. - -Client diversity refers to utilizing different software clients in a blockchain network developed by various teams and in other programming languages. - -- **Security and Resilience**: Client diversity increases the robustness of the network. If there's a bug in one client, it doesn't bring down the entire network because other clients can continue to operate. This decentralization and redundancy is a fundamental aspect of blockchain security and resilience. -- **Decentralization and Governance**: Client diversity promotes decentralization in the development and governance of the Ethereum network. It prevents any team or entity from having too much influence over the network's growth. - -:::info - -Most validator nodes on the LUKSO mainnet are running with Geth and Prysm. Node operators are responsible to ensure they split their client usage evenly to the extent of officially supported clients and validators. - -::: - -## Switching from Prysm to Lighthouse - -:::caution Validator Keys - -As a validator, you need to import your validator deposit key files (`keystore-xxx-[timestamp].json`) that you have generated using the [LUKSO Wagyu](https://github.com/lukso-network/tools-wagyu-key-gen) or [LUKSO CLI Keygen](https://github.com/lukso-network/tools-key-gen-cli) tools. Ensure you safely copy them to your node before switching to a new consensus client. - -::: - -#### Stop your Node - -If you are currently running the Prysm consensus client, stop the clients before making any adjustments. - -:::caution - -If you configured custom services on top of the LUKSO CLI, please use your service commands to stop your node. - -::: - -:::tip - -The name of the directory `myLUKSOnode/` can be changed in the examples below. - -::: - -Move into your node's working directory. - -```bash -$ cd myLUKSOnode -``` - -Make sure to stop all processes of the blockchain node. - -```bash -$ lukso stop -``` - -Afterward, you can check if your node stopped correctly. - -```bash -$ lukso status -``` - -#### Create a new Working Directory - -Move out of your current node's working directory. - -```bash -$ cd .. -``` - -Next, create a new working directory for your updated node. Your old folder will act as a backup for your previous configuration and keystore files. - -```bash -$ mkdir myNewLUKSOnode && cd myNewLUKSOnode -``` - -#### Initialize the new Working Directory - -Next, you can initialize your new working folder. The command will download the latest network configurations and genesis files to synchronize with the LUKSO blockchain. - -```bash -$ lukso init -``` - -#### Install the Latest Clients - -After the initialization is successful, we must install the new blockchain clients. - -:::tip - -It is recommended to use Erigon and Lighthouse clients to address both client majorities at once. - -::: - -:::info - -After the installation has been successful, you can continue importing your validator keys into the new validator wallet that will be used within Lighthouse. You will be asked to set a new wallet password to safely store the imported deposit keys. Further, you must input your password for the deposit keys to be encrypted and added to the wallet. - -::: - -```bash -$ lukso install -``` - -#### Importing Validator Keys - -After the installation has been successful, you can continue importing your validator keys into the new validator wallet that will be used within Lighthouse. You will be asked to set a new wallet password to store the imported deposit keys safely. Further, you will have to input your password for the deposit keys, so that they can be encrypted and added to the wallet. - -```bash -$ lukso validator import --validator-keys "./path/to/your/keys/folder" -``` - -#### Checking Validator Keys - -After importing one or multiple folders, you can check your imported keys. - -```bash -$ lukso validator list -``` - -If the imported deposit keys match the ones in the original folder, you can delete them from your node machine. - -#### Start your new Node - -You can start your node as regular. If you run your node as a validator, please adjust your flags or the recipient address. - -:::info - -In case you did any modifications to your configuration files, such as: - -- configuring a Dynamic DNS -- connecting the blockchain explorer page -- adding a node name or graffiti -- adjusting your peer count - -Please add them again and ensure these are in the correct format before starting your node. - -::: - -:::caution - -Wait 10 minutes after stopping your node so the network does not accuse you of slashing while using updated configurations. - -::: - -Start up your node using checkpoint synchronization to reduce your downtime while synchronizing with the network significantly. Fast synchronization speeds are essential if you run a validator node to avoid losing stake. - -Your node will begin syncing from a recently finalized consensus checkpoint instead of genesis. It will then download the rest of the blockchain data while your consensus is already running. After the synchronization is finalized, you will end up with the equal blockchain data. - -> You can use the flag on every startup. However, it shows the most significant effect when synchronizing from scratch or after an extended downtime. - - - - -:::info - -If you are setting up a node for the testnet, add the `--testnet` flag to the start command. - -::: - -:::note - -You will need the LUKSO CLI Version 0.8.0 or above in order to use the `--checkpoint-sync` command. If you are using an older version, please pass down the checkpoint flag as described in the [LUKSO CLI Documentation](https://github.com/lukso-network/tools-lukso-cli/tree/main#using-checkpoint-syncing). - -::: - -```sh -# Starting the Mainnet Node -$ lukso start --checkpoint-sync - -# Starting the Mainnet Validator -$ lukso start --validator --transaction-fee-recipient "0x1234" --checkpoint-sync -``` - - - - -:::caution - -The normal synchronization process will take multiple hours for the node to finalize. It is not recommended if you are running a validator. - -::: - -:::info - -If you are setting up a node for the testnet, add the `--testnet` flag to the start command. - -::: - -```bash -# Starting the Mainnet Node -$ lukso start - -# Starting the Mainnet Validator -$ lukso start --validator --transaction-fee-recipient "0x1234" -``` - - - - -:::info - -After your node finalizes the synchronization with the network, you can remove the validator key folder and the old working directory. - -::: diff --git a/docs/guides/network/update-the-node.md b/docs/guides/network/update-the-node.md deleted file mode 100644 index a66df1adf9..0000000000 --- a/docs/guides/network/update-the-node.md +++ /dev/null @@ -1,478 +0,0 @@ ---- -sidebar_label: 'Update the Node' -sidebar_position: 1 ---- - -import Tabs from '@theme/Tabs'; -import TabItem from '@theme/TabItem'; - -# Update the Node - -Updating your node and blockchain clients is of utmost importance. It is not just about having access to the latest features of the LUKSO CLI, but an essential aspect of maintaining your node's security, performance, and reliability, directly affecting the network. - -## Check your LUKSO CLI Version - -:::info Breaking Changes - -Since the mainnet launch occurred, the LUKSO CLI had breaking changes from version `0.6` to `0.7`. - -::: - -Please check your current LUKSO CLI version to determine your update process. - -```bash -$ lukso version -``` - -This guide will lead you through updating to **LUKSO CLI Version 0.8** - -## Update the LUKSO CLI - -Updating your node is similar to the installing process, while keeping your previous keystore data. If you already have the **latest LUKSO CLI version** and **network configs**, you can also just update your [blockchain clients](#updating-the-blockchain-clients). - - - - -#### Stop your Node - -:::caution - -If you configured custom services on top of the LUKSO CLI, please use your service commands to stop your node. - -::: - -:::tip - -The name of the directory `myLUKSOnode/` can be changed in the examples below. - -::: - -Move into your node's working directory. - -```bash -$ cd myLUKSOnode -``` - -Make sure to stop all processes of the blockchain node. - -```bash -$ lukso stop -``` - -Afterward, you can check if your node stopped correctly. - -```bash -$ lukso status -``` - -If you have problems stopping the processes, please use the `pkill` command to force their shutdowns. - -```bash -# Stop the Geth client -$ sudo pkill geth - -# Stop the Erigon client -$ sudo pkill erigon - -# Stop the Prysm client -$ sudo pkill prysm - -# Stop the Prysm Validator client -$ sudo pkill validator - -# Stop the Lighthouse and Lighthouse Validator clients -$ sudo pkill lighthouse -``` - -#### Create a new Working Directory - -Move out of your current node's working directory. - -```bash -$ cd .. -``` - -Next, create a new working directory for your updated node. Your old folder will act as a backup for your configuration and keystore files. - -```bash -$ mkdir myNewLUKSOnode && cd myNewLUKSOnode -``` - -#### Update the LUKSO CLI - -Re-install the LUKSO CLI to your system. You will be asked to overwrite the current version. - -```bash -$ curl https://install.lukso.network | sh -``` - -Make sure to check the downloaded version again, ensuring that the update was successful. - -```bash -$ lukso version -``` - -#### Initialize the new Working Directory - -Next, you can initialize your new working folder. The command will download the latest network configurations and genesis files to synchronize with the LUKSO blockchain. - -```bash -$ lukso init -``` - -#### Install the Latest Clients - -After the initialization is successful, we must install the updated blockchain clients. - -```bash -$ lukso install -``` - -#### Copy the Validator Keys - -In case you are running a validator, you are able to copy your keystore files to the new folder. The keystore data in your old folder will act as a backup. - -> Make sure to adjust the commands using the actual name of the previous folder instead of the placeholder. - -:::caution - -Only copy over your keystore data if you want to use the same consensus client as before the update. Otherwise, you would have to import your validator keys from scratch. - -::: - -```bash -# Copy Mainnet Node Data -$ cp -r ../myOldLUKSOnode/mainnet-keystore . - -# Copy Testnet Node Data -$ cp -r ../myOldLUKSOnode/testnet-keystore . -``` - -#### Restart your Node - -You can start your node as regular. Please adjust your flags or the recipient address in case you are running a validator. - -:::info - -In case you did any modifications to your configuration files, such as: - -- configuring a Dynamic DNS -- connecting the blockchain explorer page -- adding a node name or graffiti -- adjusting your peer count - -Please add them once again and make sure that these are in the correct format before starting your node. - -::: - -:::caution - -Wait 10 minutes after stopping your node so the network does not accuse you of slashing while using updated configurations. - -::: - -Start up your node using checkpoint synchronization to reduce your downtime while synchronizing with the network significantly. Fast synchronization speeds are essential if you run a validator node to avoid losing stake. - -Your node will begin syncing from a recently finalized consensus checkpoint instead of genesis. It will then download the rest of the blockchain data while your consensus is already running. After the synchronization is finalized, you will end up with the equal blockchain data. - -> You can use the flag on every startup. However, it shows the most significant effect when synchronizing from scratch or after an extended downtime. - - - - -:::info - -If you are setting up a node for the testnet, add the `--testnet` flag to the start command. - -::: - -```sh -# Starting the Mainnet Node -$ lukso start --checkpoint-sync - -# Starting the Mainnet Validator -$ lukso start --validator --transaction-fee-recipient "0x1234" --checkpoint-sync -``` - - - - -:::caution - -The normal synchronization process will take multiple hours for the node to finalize. It is not recommended if you are running a validator. - -::: - -:::info - -If you are setting up a node for the testnet, add the `--testnet` flag to the start command. - -::: - -```bash -# Starting the Mainnet Node -$ lukso start - -# Starting the Mainnet Validator -$ lukso start --validator --transaction-fee-recipient "0x1234" -``` - - - - -:::info - -After your node has finalized the synchronization with the network, you can remove the old working directory from your system. - -::: - - - - -#### Stop your Node - -:::caution - -If you configured custom services on top of the LUKSO CLI, please use your service commands to stop your node. - -::: - -Move into your node's working directory. - -```bash -$ cd myLUKSOnode -``` - -Make sure to stop all processes of the blockchain node. - -```bash -$ lukso stop -``` - -Afterward, you can check if your node stopped correctly. - -```bash -$ lukso status -``` - -#### Remove outdated Blockchain Data - -If the processes have been stopped successfully, you can continue to remove the old network data. - -```bash -# Remove Mainnet Data -$ rm -rf mainnet-data - -# Remove Testnet Data -$ rm -rf testnet-data -``` - -#### Backup outdated Configuration - -Next, you can rename your configuration folder to reload the latest network files later on. - -```bash -$ mv configs/ configs-backup -``` - -#### Update the LUKSO CLI - -Re-install the LUKSO CLI to your system. You will be asked to overwrite the current version. - -```bash -$ curl https://install.lukso.network | sh -``` - -Make sure to check the downloaded version again to ensure that the update was successful. - -```bash -$ lukso version -``` - -#### Re-initialize the Working Directory - -Next, you can re-download the latest network configurations and genesis files. - -```bash -$ lukso init -``` - -#### Install the Latest Clients - -After updating the LUKSO CLI, we must install the updated blockchain clients. - -```bash -$ lukso install -``` - -#### Restart your Node - -You can start your node as regular. If you run a validator, please adjust your flags or the recipient address. - -:::info - -In case you did any modifications to your configuration files, such as: - -- configuring a Dynamic DNS -- connecting the blockchain explorer page -- adding a node name or graffiti -- adjusting your peer count - -Please add them again and ensure these are in the correct format before starting your node. - -::: - -:::caution - -Wait 10 minutes after stopping your node so the network does not accuse you of slashing while using updated configurations. - -::: - -Start up your node using checkpoint synchronization to reduce your downtime while synchronizing with the network significantly. Fast synchronization speeds are essential if you run a validator node to avoid losing stake. - -Your node will begin syncing from a recently finalized consensus checkpoint instead of genesis. It will then download the rest of the blockchain data while your consensus is already running. After the synchronization is finalized, you will end up with the equal blockchain data. - -> You can use the flag on every startup. However, it shows the most significant effect when synchronizing from scratch or after an extended downtime. - - - - -:::info - -If you are setting up a node for the testnet, add the `--testnet` flag to the start command. - -::: - -```sh -# Starting the Mainnet Node -$ lukso start --checkpoint-sync - -# Starting the Mainnet Validator -$ lukso start --validator --transaction-fee-recipient "0x1234" --checkpoint-sync -``` - - - - -:::caution - -The normal synchronization process will take multiple hours for the node to finalize. It is not recommended if you are running a validator. - -::: - -:::info - -If you are setting up a node for the testnet, add the `--testnet` flag to the start command. - -::: - -```bash -# Starting the Mainnet Node -$ lukso start - -# Starting the Mainnet Validator -$ lukso start --validator --transaction-fee-recipient "0x1234" -``` - - - - -:::info - -After your node has finalized the synchronization with the network, you can remove the `configs-backup` folder from your system. - -::: - - - - -## Update the Blockchain Clients - -If you already use the **latest LUKSO CLI version** and **network configuration** but want to check for new blockchain client versions, you can update them separately. - -### Stop your Node - -:::caution - -If you configured custom services on top of the LUKSO CLI, please use your service commands to stop your node. - -::: - -Move into your node's working directory. - -```bash -$ cd myLUKSOnode -``` - -Stop all processes of the blockchain node. - -```bash -$ lukso stop -``` - -Afterward, you can check if your node stopped correctly. - -```bash -$ lukso status -``` - -### Download new Clients - -Then continue to check and update your configured blockchain clients. - -```bash -$ lukso update -``` - -#### Restart your Node - -You can start your node as regular. If you run a validator, please adjust your flags or the recipient address. - -Start up your node using checkpoint synchronization to reduce your downtime while synchronizing with the network significantly. Fast synchronization speeds are essential if you run a validator node to avoid losing stake. - -Your node will begin syncing from a recently finalized consensus checkpoint instead of genesis. It will then download the rest of the blockchain data while your consensus is already running. After the synchronization is finalized, you will end up with the equal blockchain data. - -> You can use the flag on every startup. However, it shows the most significant effect when synchronizing from scratch or after an extended downtime. - - - - -:::info - -If you are setting up a node for the testnet, add the `--testnet` flag to the start command. - -::: - -```sh -# Starting the Mainnet Node -$ lukso start --checkpoint-sync - -# Starting the Mainnet Validator -$ lukso start --validator --transaction-fee-recipient "0x1234" --checkpoint-sync -``` - - - - -:::caution - -The normal synchronization process will take multiple hours for the node to finalize. It is not recommended if you are running a validator. - -::: - -:::info - -If you are setting up a node for the testnet, add the `--testnet` flag to the start command. - -::: - -```bash -# Starting the Mainnet Node -$ lukso start - -# Starting the Mainnet Validator -$ lukso start --validator --transaction-fee-recipient "0x1234" -``` - - - diff --git a/docusaurus.config.js b/docusaurus.config.js index 68795ec9cb..bd24085f79 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -53,6 +53,14 @@ module.exports = { from: '/contracts/erc725-account', to: '/contracts/contracts/LSP0ERC725Account', }, + { + from: '/guides/network/update-the-node', + to: '/networks/network/update-the-node', + }, + { + from: '/guides/network/switch-consensus-clients', + to: '/networks/network/switch-consensus-clients', + }, { from: '/contracts/key-manager', to: '/contracts/contracts/LSP6KeyManager', From 746d5e8485de4bcd980c6349a269a353904a4392 Mon Sep 17 00:00:00 2001 From: CJ42 Date: Thu, 5 Oct 2023 14:48:36 +0100 Subject: [PATCH 5/5] add redirect link for SEO --- docusaurus.config.js | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docusaurus.config.js b/docusaurus.config.js index 68795ec9cb..05b64d0f9f 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -126,6 +126,10 @@ module.exports = { from: '/standards/smart-contracts/lsp14-ownable-2-step', to: '/contracts/contracts/LSP14Ownable2Step', }, + { + from: '/standards/smart-contracts/lsp16-universal-factory', + to: '/contracts/contracts/LSP16UniversalFactory', + }, // FAQ new Structure { from: '/faq/network/network',