From 4aad675ed01488886a8449781a5b2e319065fa7e Mon Sep 17 00:00:00 2001 From: alexcss Date: Tue, 27 Aug 2024 12:42:54 +0300 Subject: [PATCH] Crowdin Machine Translation --- crowdin.yml | 13 + .../powpeg/hsm-firmware-attestation.md | 10 +- docs/01-concepts/rbtc/conversion.md | 2 + docs/01-concepts/rbtc/networks.md | 8 + docs/02-developers/02-requirements/index.md | 16 +- docs/02-developers/04-quickstart/index.md | 2 + .../04-quickstart/web3-python.md | 24 +- .../02-hardhat/interact-with-frontend.md | 8 +- .../06-integrate/01-rif-relay/sample-dapp.md | 8 +- docs/02-developers/07-rpc-api/01-setup.md | 21 +- docs/02-developers/07-rpc-api/02-methods.md | 98 +- .../02-configure-mining/index.md | 8 +- .../04-setup/02-installation/docker.md | 6 +- .../04-setup/02-installation/java.md | 14 +- .../04-setup/03-configuration/preferences.md | 6 +- .../04-setup/reproducible-build.md | 14 +- .../04-setup/security-chain.md | 10 +- .../09-troubleshooting/index.md | 4 +- docs/04-resources/03-faqs/index.md | 18 +- docs/04-resources/04-tutorials/index.md | 16 +- .../05-port-to-rootstock/ethereum-dapp.md | 20 +- .../05-port-to-rootstock/index.md | 6 +- .../04-resources/06-guides/tokenbridge/faq.md | 8 +- .../06-guides/two-way-peg-app/faqs.md | 10 +- .../06-guides/two-way-peg-app/glossary.md | 6 +- docs/05-dev-tools/index.md | 2 + docs/05-dev-tools/wallets/index.md | 6 +- docs/05-dev-tools/wallets/metamask.md | 6 +- .../2024-07-04-introducing-arrowhead-6-3-0.md | 9 + .../2024-07-10-introducing-arrowhead-6-3-1.md | 9 + .../01-concepts/account-based-addresses.md | 69 + .../current/01-concepts/fundamentals/index.md | 60 + .../01-concepts/fundamentals/stack/index.md | 49 + .../current/01-concepts/index.md | 60 +- .../01-concepts/merged-mining/index.md | 42 + .../powpeg/hsm-firmware-attestation.md | 41 + .../current/01-concepts/powpeg/index.md | 111 ++ .../01-concepts/powpeg/security-model.md | 31 + .../rbtc/conversion-with-ledger.md | 225 ++++ .../rbtc/conversion-with-node-console.md | 81 ++ .../rbtc/conversion-with-trezor.md | 52 + .../current/01-concepts/rbtc/conversion.md | 86 ++ .../current/01-concepts/rbtc/gas.md | 149 +++ .../current/01-concepts/rbtc/index.md | 88 ++ .../current/01-concepts/rbtc/networks.md | 217 +++ .../current/01-concepts/rif-suite/index.md | 22 + .../01-concepts/rif-suite/token/index.md | 110 ++ .../02-developers/02-requirements/index.md | 156 +++ .../02-overview/index.md | 134 ++ .../03-browser/index.md | 130 ++ .../04-transactions/index.md | 101 ++ .../03-blockchain-essentials/index.md | 22 + .../02-developers/04-quickstart/hardhat.md | 161 +++ .../02-developers/04-quickstart/index.md | 101 ++ .../04-quickstart/rootstock-etherspot.md | 157 +++ .../02-developers/04-quickstart/wagmi.md | 307 +++++ .../04-quickstart/web3-python.md | 632 +++++++++ .../02-hardhat/configure-hardhat-rootstock.md | 89 ++ .../02-hardhat/create-hardhat-project.md | 45 + .../02-hardhat/deploy-smart-contracts.md | 147 +++ .../05-smart-contracts/02-hardhat/index.md | 39 + .../02-hardhat/interact-with-frontend.md | 373 ++++++ .../02-hardhat/test-smart-contracts.md | 85 ++ .../02-hardhat/troubleshooting.md | 44 + .../02-hardhat/write-smart-contracts.md | 76 ++ .../03-interface-registry/index.md | 57 + .../04-verify-smart-contracts/index.md | 178 +++ .../05-smart-contracts/05-foundry/index.md | 202 +++ .../05-smart-contracts/contract-addresses.md | 36 + .../02-developers/05-smart-contracts/index.md | 22 + .../verify-address-ownership.md | 242 ++++ .../06-integrate/01-rif-relay/_category_.yml | 5 + .../06-integrate/01-rif-relay/architecture.md | 278 ++++ .../06-integrate/01-rif-relay/contracts.md | 135 ++ .../06-integrate/01-rif-relay/deployment.md | 371 ++++++ .../06-integrate/01-rif-relay/develop.md | 30 + .../06-integrate/01-rif-relay/gas-costs.md | 33 + .../01-rif-relay/installation-requirements.md | 54 + .../06-integrate/01-rif-relay/integrate.md | 306 +++++ .../06-integrate/01-rif-relay/overview.md | 22 + .../06-integrate/01-rif-relay/sample-dapp.md | 144 ++ .../01-rif-relay/smart-wallets.md | 80 ++ .../06-integrate/01-rif-relay/versions.md | 67 + .../02-developers/06-integrate/_category_.yml | 5 + .../02-developers/07-rpc-api/01-setup.md | 127 ++ .../02-developers/07-rpc-api/02-methods.md | 1172 +++++++++++++++++ .../02-developers/07-rpc-api/_category_.yml | 5 + .../01-rsk-precompiled-abis/index.md | 86 ++ .../02-developers/08-libraries/_category_.yml | 5 + .../08-libraries/rif-wallet-libs.md | 63 + .../current/02-developers/index.md | 36 + .../current/04-resources/01-courses/index.md | 32 + package.json | 1 + 93 files changed, 8309 insertions(+), 165 deletions(-) create mode 100644 crowdin.yml create mode 100644 i18n/es/docusaurus-plugin-content-blog-changelog/2024-07-04-introducing-arrowhead-6-3-0.md create mode 100644 i18n/es/docusaurus-plugin-content-blog-changelog/2024-07-10-introducing-arrowhead-6-3-1.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/account-based-addresses.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/fundamentals/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/fundamentals/stack/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/merged-mining/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/powpeg/hsm-firmware-attestation.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/powpeg/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/powpeg/security-model.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion-with-ledger.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion-with-node-console.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion-with-trezor.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/gas.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/networks.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rif-suite/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rif-suite/token/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/02-requirements/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/02-overview/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/03-browser/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/04-transactions/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/hardhat.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/rootstock-etherspot.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/wagmi.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/web3-python.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/configure-hardhat-rootstock.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/create-hardhat-project.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/deploy-smart-contracts.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/interact-with-frontend.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/test-smart-contracts.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/troubleshooting.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/write-smart-contracts.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/03-interface-registry/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/04-verify-smart-contracts/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/05-foundry/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/contract-addresses.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/verify-address-ownership.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/_category_.yml create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/architecture.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/contracts.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/deployment.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/develop.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/gas-costs.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/installation-requirements.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/integrate.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/overview.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/sample-dapp.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/smart-wallets.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/versions.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/_category_.yml create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/07-rpc-api/01-setup.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/07-rpc-api/02-methods.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/07-rpc-api/_category_.yml create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/08-libraries/01-rsk-precompiled-abis/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/08-libraries/_category_.yml create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/08-libraries/rif-wallet-libs.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/02-developers/index.md create mode 100644 i18n/es/docusaurus-plugin-content-docs/current/04-resources/01-courses/index.md diff --git a/crowdin.yml b/crowdin.yml new file mode 100644 index 00000000..318d6f13 --- /dev/null +++ b/crowdin.yml @@ -0,0 +1,13 @@ +project_id: 683600 +api_token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx +preserve_hierarchy: true +files: + # JSON translation files + - source: /i18n/en/**/* + translation: /i18n/%two_letters_code%/**/%original_file_name% + # Docs Markdown files + - source: /docs/**/* + translation: /i18n/%two_letters_code%/docusaurus-plugin-content-docs/current/**/%original_file_name% + # Blog Markdown files + - source: /changelog/**/* + translation: /i18n/%two_letters_code%/docusaurus-plugin-content-blog-changelog/**/%original_file_name% diff --git a/docs/01-concepts/powpeg/hsm-firmware-attestation.md b/docs/01-concepts/powpeg/hsm-firmware-attestation.md index b3387b5f..a75c4285 100644 --- a/docs/01-concepts/powpeg/hsm-firmware-attestation.md +++ b/docs/01-concepts/powpeg/hsm-firmware-attestation.md @@ -19,14 +19,16 @@ To verify the Powpeg nodes, follow the HSM firmware attestation process using th ### Frequently Asked Questions +````mdx-code-block - What is the multisig scheme for the powHSM? It is a M of N multisig. + What is the multisig scheme for the powHSM? It is a M of N multisig. What is M and what is N? - > - A: The best way to get this information is by querying the Bridge directly, since the number of members of the PowPeg may change after a PowPeg composition change. - > - You can use the following methods to query the bridge: `getFederationSize`, `getFederationThreshold`. + > - A: The best way to get this information is by querying the Bridge directly, since the number of members of the PowPeg may change after a PowPeg composition change. + > - You can use the following methods to query the bridge: `getFederationSize`, `getFederationThreshold`. > - By consensus the required amount of signers (M) will always be half plus one the total amount of pegnatories `M = N / 2 + 1`. See the signatories and attestation information in [PowPeg HSM Firmware Attestation](#powpeg-hsm-firmware-attestation---sovryn). - \ No newline at end of file + +```` diff --git a/docs/01-concepts/rbtc/conversion.md b/docs/01-concepts/rbtc/conversion.md index 75c56174..e438a854 100644 --- a/docs/01-concepts/rbtc/conversion.md +++ b/docs/01-concepts/rbtc/conversion.md @@ -53,6 +53,7 @@ Watch this explainer video on **How to do BTC & R-BTC Conversions using the Root ### FAQs +````mdx-code-block How often does the Rootstock Federation address change? @@ -67,6 +68,7 @@ Watch this explainer video on **How to do BTC & R-BTC Conversions using the Root +```` ### Feedback diff --git a/docs/01-concepts/rbtc/networks.md b/docs/01-concepts/rbtc/networks.md index 713000c6..d845f009 100644 --- a/docs/01-concepts/rbtc/networks.md +++ b/docs/01-concepts/rbtc/networks.md @@ -18,6 +18,7 @@ The minimum amount of Bitcoin to convert is **0.005 BTC** for Mainnet. Instructions on how to do a Mainnet peg-in. +````mdx-code-block 1. Get a BTC address with balance @@ -69,11 +70,13 @@ Instructions on how to do a Mainnet peg-in. +```` ### RBTC to BTC conversion Instructions on how to do a Mainnet peg-out. +````mdx-code-block 1. Get BTC address with RBTC private key @@ -97,6 +100,7 @@ Instructions on how to do a Mainnet peg-out. +```` ## Testnet Conversion @@ -110,6 +114,7 @@ The minimum amount of Bitcoin to convert is **0.005 tBTC** for Testnet. Instructions on how to do a Testnet peg-in. +````mdx-code-block 1. Connect a wallet to Bitcoin Testnet @@ -164,6 +169,7 @@ Instructions on how to do a Testnet peg-in. +```` ### tRBTC to tBTC conversion @@ -173,6 +179,7 @@ Instructions on how to do a Testnet peg-out. The release process on Bitcoin network takes 10 Rootstock block confirmations and at least 10 more minutes. ::: +````mdx-code-block 1. Get tBTC address with tRBTC private key @@ -198,3 +205,4 @@ The release process on Bitcoin network takes 10 Rootstock block confirmations an +```` diff --git a/docs/02-developers/02-requirements/index.md b/docs/02-developers/02-requirements/index.md index f96866b1..db566342 100644 --- a/docs/02-developers/02-requirements/index.md +++ b/docs/02-developers/02-requirements/index.md @@ -20,7 +20,7 @@ See how to setup the RPC API and get an [API Key](/developers/rpc-api/setup). ## Network Configuration -Fill these values to connect to the Rootstock Mainnet or Testnet. +Fill these values to connect to the Rootstock Mainnet or Testnet. @@ -100,6 +100,7 @@ npm i -g hardhat-shorthand ### POSIX Compliant Shell +````mdx-code-block Standard terminals like `cmd` or PowerShell may not support some commands. We recommended installing [Git for Windows](https://gitforwindows.org/) for Git Bash, which provides a more UNIX-like experience. Here's a [tutorial on Git Bash](https://www.atlassian.com/git/tutorials/git-bash). @@ -108,26 +109,28 @@ npm i -g hardhat-shorthand Standard terminal. +```` ### Installing Node.js and NPM +````mdx-code-block - - Node v18 or later. + - Node v18 or later. - For installation, use [NVM install script](https://github.com/nvm-sh/nvm#install--update-script). 1. Download the Node.js Installer from [Node.js Downloads](https://nodejs.org/en/download). 2. Run the installer and follow the on-screen instructions. - 3. Open Command Prompt or PowerShell and check versions with `node -v` and `npm -v`. + 3. Open Command Prompt or PowerShell and check versions with `node -v` and `npm -v`. - See Posix Compliant Shell. 1. Install Homebrew (if not installed): ```bash /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh) - ``` - 2. Install Node.js and npm with `brew install node` + ``` + 2. Install Node.js and npm with `brew install node` 3. Check versions in Terminal with `node -v` and `npm -v` @@ -137,8 +140,9 @@ npm i -g hardhat-shorthand 4. Check versions in the terminal with `node -v` and `npm -v` +```` ## Optional Setup - [Foundry](/developers/smart-contracts/foundry) -- [Remix](https://remix.ethereum.org/) \ No newline at end of file +- [Remix](https://remix.ethereum.org/) diff --git a/docs/02-developers/04-quickstart/index.md b/docs/02-developers/04-quickstart/index.md index 37909ab8..8084954f 100644 --- a/docs/02-developers/04-quickstart/index.md +++ b/docs/02-developers/04-quickstart/index.md @@ -6,6 +6,7 @@ tags: [rsk, rootstock, beginner, quick starts, developers, advanced, port to roo description: "Quick starts, demos and starter kits to develop on Rootstock." --- +````mdx-code-block +```` diff --git a/docs/02-developers/04-quickstart/web3-python.md b/docs/02-developers/04-quickstart/web3-python.md index fca4f7d0..ac2fa3fe 100644 --- a/docs/02-developers/04-quickstart/web3-python.md +++ b/docs/02-developers/04-quickstart/web3-python.md @@ -16,7 +16,7 @@ See tutorial on how to [interact with Rootstock using Rust](/resources/tutorials ## Prerequisites -- A testnet account with tRBTC funds. +- A testnet account with tRBTC funds. - [Get tRBTC](https://faucet.rootstock.io/). - An API KEY from the [Rootstock RPC Service](https://rpc.rootstock.io/). - Set up the project @@ -70,7 +70,7 @@ add the following variables to the file: Replace `YOUR_APIKEY` with the API key from your dashboard. ```bash -# get this YOUR_APIKEY from the Rootstock RPC Service. +# get this YOUR_APIKEY from the Rootstock RPC Service. RPC_PROVIDER_APIKEY = '{YOUR_APIKEY}' # this is the private key of the account from which you will deploy the contract @@ -82,7 +82,7 @@ ACCOUNT_PRIVATE_KEY = '{YOUR_PRIVATE_KEY}' ### Write the smart contract -The contract to be compiled and deployed in the next section is a simple contract that stores a message, and will allow for setting different messages by sending a transaction. +The contract to be compiled and deployed in the next section is a simple contract that stores a message, and will allow for setting different messages by sending a transaction. You can get started by creating a file for the contract: @@ -189,7 +189,7 @@ account_from = { ``` 4. Create a contract instance using the `web3.eth.contract` function and passing in the ABI and bytecode of the contract -5. Set the [gas price strategy](https://web3py.readthedocs.io/en/stable/gas_price.html#gas-price) using the `web3.eth.set_gas_price_strategy` function, which will allow us to fetch the gasPrice from the RPC Provider. This is important because otherwise the Web3 library will attempt to use `eth_maxPriorityFeePerGas` and `eth_feeHistory` RPC methods, which are only supported by post-London Ethereum nodes. +5. Set the [gas price strategy](https://web3py.readthedocs.io/en/stable/gas_price.html#gas-price) using the `web3.eth.set_gas_price_strategy` function, which will allow us to fetch the gasPrice from the RPC Provider. This is important because otherwise the Web3 library will attempt to use `eth_maxPriorityFeePerGas` and `eth_feeHistory` RPC methods, which are only supported by post-London Ethereum nodes. 6. Build a constructor transaction using the contract instance. You will then use the `build_transaction` function to pass in the transaction information including the `from` address and the `nonce` for the sender. To get the `nonce` you can use the `web3.eth.get_transaction_count` function 7. Sign the transaction using the `web3.eth.account.sign_transaction` function and pass in the constructor transaction and the `private_key` of the sender 8. Using the signed transaction, you can then send it using the `web3.eth.send_raw_transaction` function and wait for the transaction receipt by using the `web3.eth.wait_for_transaction_receipt` function @@ -317,7 +317,7 @@ python getMessage.py ### Write data to the contract (Write Methods) -Write methods are the type of interaction that modify the contract's storage (change variables), meaning a transaction needs to be signed and sent. In this section, you'll create the script to change the text stored in the Greeter contract. +Write methods are the type of interaction that modify the contract's storage (change variables), meaning a transaction needs to be signed and sent. In this section, you'll create the script to change the text stored in the Greeter contract. To get started, you can create a file for the script and name it `setMessage.py`: @@ -331,7 +331,7 @@ Open the `setMessage.py` file and take the following steps to create the script: 2. Set up the Web3 provider 3. Define the `account_from` variable, including the `private_key`, and the `contract_address` of the deployed contract. The private key is required to sign the transaction. Note: This is for example purposes only. Never store your private keys in your code 4. Create a contract instance using the `web3.eth.contract` function and passing in the ABI and address of the deployed contract -5. Set the gas price strategy using the `web3.eth.set_gas_price_strategy` function, which will allow us to fetch the gasPrice from the RPC Provider. This is important because otherwise the Web3 library will attempt to use `eth_maxPriorityFeePerGas` and `eth_feeHistory` RPC methods, which are only supported by post-London Ethereum nodes. +5. Set the gas price strategy using the `web3.eth.set_gas_price_strategy` function, which will allow us to fetch the gasPrice from the RPC Provider. This is important because otherwise the Web3 library will attempt to use `eth_maxPriorityFeePerGas` and `eth_feeHistory` RPC methods, which are only supported by post-London Ethereum nodes. 6. Build the `setGreeting` transaction using the contract instance and passing in the new message. You'll then use the `build_transaction` function to pass in the transaction information including the `from` address and the `nonce` for the sender. To get the `nonce` you can use the `web3.eth.get_transaction_count` function 7. Sign the transaction using the `web3.eth.account.sign_transaction` function and pass in the `setGreeting` transaction and the `private_key` of the sender 8. Using the signed transaction, you can then send it using the `web3.eth.send_raw_transaction` function and wait for the transaction receipt by using the `web3.eth.wait_for_transaction_receipt` function @@ -386,7 +386,7 @@ txn_receipt = web3.eth.wait_for_transaction_receipt(txn_hash) print(f"Transaction successful with hash: { txn_receipt.transactionHash.hex() }") ``` -If successful, the transaction hash will be displayed in the terminal. +If successful, the transaction hash will be displayed in the terminal. ```python python setMessage.py @@ -538,10 +538,11 @@ Transaction successful with hash: 0x79ab8be672b0218d31f81876c34321ee7b08e6a4ec8b ## Summary -In this guide, we learnt how to use the Web3.py library to deploy, interact with a smart contract and send transactions on Rootstock. +In this guide, we learnt how to use the Web3.py library to deploy, interact with a smart contract and send transactions on Rootstock. ## Troubleshooting +````mdx-code-block 1. Error message: eth_sendTransaction method does not exist @@ -550,8 +551,8 @@ In this guide, we learnt how to use the Web3.py library to deploy, interact with ```bash web3.exceptions.MethodUnavailable: {'code': -32601, 'message': 'The method eth_sendTransaction does not exist/is not available. See available methods at https://dev.rootstock.io/developers/rpc-api/methods'} ``` - - Note: The cause of the error on the deployment is that the Web3.py module is set to use the private keys of the RPC provider (Hosted Keys), which is a legacy way to use accounts, and is not supported by modern RPC providers, as they do not store private keys. - - Methods like `web3.eth.send_transaction` do not work with RPC providers, because they rely on a node state and all modern nodes are stateless, which underneath make JSON-RPC calls to methods like `eth_accounts` and `eth_sendTransaction`. You must always use local private keys when working with nodes hosted by someone else. + - Note: The cause of the error on the deployment is that the Web3.py module is set to use the private keys of the RPC provider (Hosted Keys), which is a legacy way to use accounts, and is not supported by modern RPC providers, as they do not store private keys. + - Methods like `web3.eth.send_transaction` do not work with RPC providers, because they rely on a node state and all modern nodes are stateless, which underneath make JSON-RPC calls to methods like `eth_accounts` and `eth_sendTransaction`. You must always use local private keys when working with nodes hosted by someone else. - If unfamiliar, note that you can [export your private keys from Metamask](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key) and other wallets. Remember to never share your private keys, and do not put it on your code or repository. - In order to successfully deploy the contract, the developer needs to set up Web3.py to use his Local Private Keys, and to build and pre-sign the transaction before sending it, so the module uses `eth_sendRawTransaction` instead. - To allow Web3.py to use the local keys, we have to use the Signing middleware to add the Private Key to the signing keychain. @@ -612,6 +613,7 @@ In this guide, we learnt how to use the Web3.py library to deploy, interact with +```` #### Resources - [Web3.py: Gas Price Strategy](https://web3py.readthedocs.io/en/stable/gas_price.html#gas-price) @@ -620,4 +622,4 @@ In this guide, we learnt how to use the Web3.py library to deploy, interact with - [Web3.py: Working with Local Private Keys](https://web3py.readthedocs.io/en/stable/web3.eth.account.html#working-with-local-private-keys) - [Web3.py: Contract Deployment Example](https://web3py.readthedocs.io/en/stable/web3.contract.html) - [Web3.py: Sign a Contract Transaction](https://web3py.readthedocs.io/en/stable/providers.html) -- [Web3.py: Setting up an RPC Provider](https://web3py.readthedocs.io/en/stable/providers.html) \ No newline at end of file +- [Web3.py: Setting up an RPC Provider](https://web3py.readthedocs.io/en/stable/providers.html) diff --git a/docs/02-developers/05-smart-contracts/02-hardhat/interact-with-frontend.md b/docs/02-developers/05-smart-contracts/02-hardhat/interact-with-frontend.md index 3f16624d..39b89ec1 100644 --- a/docs/02-developers/05-smart-contracts/02-hardhat/interact-with-frontend.md +++ b/docs/02-developers/05-smart-contracts/02-hardhat/interact-with-frontend.md @@ -11,7 +11,7 @@ Creating a user-friendly web interface for smart contracts on the Rootstock netw ## Project Setup 1. Create a new folder called `frontend` and navigate to the directory: - + ```shell mkdir frontend cd frontend @@ -323,12 +323,13 @@ Navigate to the URL: `http://127.0.0.1:8080` to test the code in the browser and These tools are specifically tailored for Web3 development, and they can simplify the integration of blockchain functionaity into web interfaces. Here are a few recommended tools and libraries that are popular in the Web3 space, along with brief descriptions: +````mdx-code-block 1. RainbowKit - [RainbowKit](https://www.rainbowkit.com/) is a React library offering a comprehensive wallet connection solution. It provides a beautiful, easy-to-use wallet connection interface that supports multiple wallets and networks. - - **Why Use It:** + - **Why Use It:** It is great for projects where you want a seamless and user-friendly wallet connection experience. It's easy to integrate and manage, especially in React-based applications. @@ -359,4 +360,5 @@ These tools are specifically tailored for Web3 development, and they can simplif - [Foundry](https://book.getfoundry.sh) is a smart contract development toolchain, and user-friendly development environment used for writing and advanced smart contracts testing in Solidity. - \ No newline at end of file + +```` diff --git a/docs/02-developers/06-integrate/01-rif-relay/sample-dapp.md b/docs/02-developers/06-integrate/01-rif-relay/sample-dapp.md index 7a2f10b9..5c33e2d8 100644 --- a/docs/02-developers/06-integrate/01-rif-relay/sample-dapp.md +++ b/docs/02-developers/06-integrate/01-rif-relay/sample-dapp.md @@ -35,6 +35,7 @@ To learn more about Metatmask and how to add it to Rootstock programmatically, s To set up RIF relay contract, clone the RIF Relay Contracts Repository: https://github.com/rsksmart/rif-relay-contracts, then follow the [RIF Relay Deployment](/developers/integrate/rif-relay/deployment/) guide to deploy an RIF Relay contract, enable revenue sharing, and whitelist the token by allowing it. +````mdx-code-block Check allowed tokens @@ -68,13 +69,14 @@ To set up RIF relay contract, clone the RIF Relay Contracts Repository: https:// --token-address 0x6f217dEd6c86A57f1211F464302e6fA544045B4f \ --amount 10000000000000000000 \ --receiver \ - --network regtest + --network regtest ``` - Import the minted token into the wallet. - To see the token in the wallet, click on “import tokens”, and then paste the token address. +```` ### Step 4: Set up RIF Relay Server @@ -97,7 +99,7 @@ This sample dApp shows you how to send transactions to the Rootstock blockchain - Configure environment variables Create a new file named `.env` in the top directory, and add the following lines in it (with the contract addresses generated when we deployed the contracts) in the **Set up RIF Relay Contracts** section above: - + ```bash REACT_APP_CONTRACTS_RELAY_HUB=0x463F29B11503e198f6EbeC9903b4e5AaEddf6D29 REACT_APP_CONTRACTS_DEPLOY_VERIFIER=0x14f6504A7ca4e574868cf8b49e85187d3Da9FA70 @@ -135,4 +137,4 @@ Create a new file named `.env` in the top directory, and add the following line - For commands to mint token, See step 6 in the Set up RIF Relay contracts section above. ![Mint Tokens](/img/rif-relay/starter-kit/mint-tokens.png) - Transfer to different addresses, using TKN for transfer fees payment, instead of RBTC -![Transfer using TKN](/img/rif-relay/starter-kit/transfer-using-tkn.png) \ No newline at end of file +![Transfer using TKN](/img/rif-relay/starter-kit/transfer-using-tkn.png) diff --git a/docs/02-developers/07-rpc-api/01-setup.md b/docs/02-developers/07-rpc-api/01-setup.md index f4e20c68..587abcef 100644 --- a/docs/02-developers/07-rpc-api/01-setup.md +++ b/docs/02-developers/07-rpc-api/01-setup.md @@ -8,15 +8,12 @@ description: "Easily create, interact and deploy EVM compatible smart contracts The [RPC API](http://rpc.rootstock.io/) provides a seamless and intuitive web interface for developers to interact with [Rootstock nodes](/node-operators/setup/) via [JSON-RPC](/node-operators/json-rpc/methods/) methods. It aims to address the challenges faced by developers when trying to access critical information like logs, transactions, and balances through RPC, which can significantly impact the timely development of dApps on the Rootstock blockchain. -In this guide, you will learn: +In this guide, you will learn: - How to create an account and [make your first API call](#getting-started) -- View a list of [JSON-RPC methods](/node-operators/json-rpc/methods/) available. +- View a list of [JSON-RPC methods](/node-operators/json-rpc/methods/) available. -
- - Use the RPC API -
+[Use the RPC API](http://rpc.rootstock.io/) ## Who is it for? @@ -58,29 +55,37 @@ To get an API key: Log in to the dashboard, and click on _New API key_: +````mdx-code-block
Generate an API key
+```` Choose a name to identify your `apikey`, and the Network (either `Testnet` or `Mainnet`). You can also add a description (optional). Click on **Create**. +````mdx-code-block
Create API key
+```` ### Make first API Call Click on the newly created `apikey` to get the details: +````mdx-code-block
- Make First API Call + Make First API Call
+```` You can make your first api call by using one of the provided examples, or simply by adding a url and `apikey` to your application. +````mdx-code-block
Connect API
+```` #### Example Request @@ -111,4 +116,4 @@ Join the [Rootstock Discord](https://rootstock.io/discord) to get support or giv - Supported [JSON RPC Methods](/node-operators/json-rpc/methods/) - [Quick Start Guide with Hardhat](/developers/smart-contracts/hardhat/) -- [RBTC Faucet](https://faucet.rootstock.io/) \ No newline at end of file +- [RBTC Faucet](https://faucet.rootstock.io/) diff --git a/docs/02-developers/07-rpc-api/02-methods.md b/docs/02-developers/07-rpc-api/02-methods.md index cfaa5aa3..754e0826 100644 --- a/docs/02-developers/07-rpc-api/02-methods.md +++ b/docs/02-developers/07-rpc-api/02-methods.md @@ -58,7 +58,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC ``` ## eth_call - Executes a new message call immediately without creating a transaction on the blockchain. -- _Params:_ +- _Params:_ - `transaction`: object, the transaction call object which contains the following fields: - **from:** String, the address from which the transaction is sent - **to:** String, required, the address to which the transaction is addressed @@ -69,7 +69,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - `blockNumber`: String, required. The number of the block (in hex) from which the number of transactions is required, OR one of the following block tags: - **latest:** the most recent block the client has available. - **earliest:** the lowest numbered block the client has available. - - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from a local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from a local mempool. Intuitively, you can think of these as blocks that have not been mined yet. - **Example:** ```shell curl --location 'https://rpc.testnet.rootstock.io/' \ @@ -79,12 +79,12 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC --data '{ "jsonrpc":"2.0", "method":"eth_call", - "params":[{"from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155", - "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567", - "gas": "0x76c0", - "gasPrice": "0x9184e72a000", - "value": "0x9184e72a", - "data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"}, + "params":[{"from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155", + "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567", + "gas": "0x76c0", + "gasPrice": "0x9184e72a000", + "value": "0x9184e72a", + "data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"}, "latest" ], "id":0 @@ -128,7 +128,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC ``` ## eth_estimateGas - _Method:_ - - Generates and returns an estimate of how much gas is necessary to allow the transaction to complete. The transaction will not be added to the blockchain. + - Generates and returns an estimate of how much gas is necessary to allow the transaction to complete. The transaction will not be added to the blockchain. - _Params:_ - **transaction:** object, the transaction call object which contains the following fields: - **from:** String, the address from which the transaction is sent @@ -140,7 +140,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - `blockNumber`: String, optional. The number of the block (in hex) from which the number of transactions is required, OR one of the following block tags: - **latest:** the most recent block the client has available. - **earliest:** the lowest numbered block the client has available. - - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. - **Example:** ```shell curl --location 'https://rpc.testnet.rootstock.io/' \ @@ -150,12 +150,12 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC --data '{ "jsonrpc":"2.0", "method":"eth_estimateGas", - "params":[{"from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155", - "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567", - "gas": "0x76c0", - "gasPrice": "0x9184e72a000", - "value": "0x9184e72a", - "data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"}, + "params":[{"from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155", + "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567", + "gas": "0x76c0", + "gasPrice": "0x9184e72a000", + "value": "0x9184e72a", + "data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"}, "latest" ], "id":0 @@ -203,7 +203,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - **Block:** String: optional, either the hexadecimal value of a **blockNumber**, OR a blockHash, OR one of the following block tags: - **Latest:** the most recent block the client has available. - **Earliest:** the lowest numbered block the client has available. - - **Pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - **Pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. - if not specified, it will return the balance at the latest block available. - Example request by `blockNumber`: ```shell @@ -215,7 +215,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC "jsonrpc":"2.0", "method":"eth_getBalance", "params":[ - "0x1fab9a0e24ffc209b01faa5a61ad4366982d0b7f", + "0x1fab9a0e24ffc209b01faa5a61ad4366982d0b7f", "latest"], "id":0 }' @@ -281,7 +281,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - Returns information about a block by `blockHash`. - _Params:_ - **Block:** String: required, the hash of a block. - - **Option:** Boolean, optional. + - **Option:** Boolean, optional. - **false:** returns only the hashes of the transactions (default) - **true:** returns the full transactions objects - _Returns:_ @@ -304,11 +304,11 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - **timestamp:** The unix timestamp for when the block was collated. - **transactions:** Array of transaction objects - please see eth_getTransactionByHash for exact shape. - **uncles:** Array of uncle hashes. - - **minimumGasPrice:** Minimum gas price a transaction should have in order to be included in that block. - - **bitcoinMergedMiningHeader:** It is the Bitcoin block header of the block that was used for merged mining the RSK block. + - **minimumGasPrice:** Minimum gas price a transaction should have in order to be included in that block. + - **bitcoinMergedMiningHeader:** It is the Bitcoin block header of the block that was used for merged mining the RSK block. - **bitcoinMergedMiningCoinbaseTransaction:** It is the coinbase transaction of the Bitcoin block that was used for merged mining the RSK block. - **bitcoinMergedMiningMerkleProof:** It is the Merkle proof that links the Bitcoin block's Merkle root with the coinbase transaction. - - **hashForMergedMining:** It is a hash that is calculated from various fields in the RSK block header. + - **hashForMergedMining:** It is a hash that is calculated from various fields in the RSK block header. - **paidFees:** It represents the total amount of fees paid by all transactions included in the block. - **cumulativeDifficulty:** It represents the total difficulty of the chain up to the current block. - **Example Request:** @@ -321,11 +321,11 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC "jsonrpc":"2.0", "method":"eth_getBlockByHash", "params":[ - "0xcca8612942582f1a890231a25245174d6947b7e2e990adf74e84c035c52b104f", + "0xcca8612942582f1a890231a25245174d6947b7e2e990adf74e84c035c52b104f", false], "id":0 }' - ``` + ``` - Example Response: ```shell { @@ -375,7 +375,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - latest: the most recent block the client has available. - earliest: the lowest numbered block the client has available. - pending: A sample next block built by the client on top of latest and containing the set of transactions usually taken from a local mempool. Intuitively, you can think of these as blocks that have not been mined yet. - - Option: Boolean, optional. + - Option: Boolean, optional. - false: returns only the hashes of the transactions (default) - true: returns the full transactions object - Returns: @@ -398,11 +398,11 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - timestamp - The unix timestamp for when the block was collated. - transactions - Array of transaction objects - please see eth_getTransactionByHash for exact shape. - uncles - Array of uncle hashes. - - minimumGasPrice: minimum gas price a transaction should have in order to be included in that block. - - bitcoinMergedMiningHeader: It is the Bitcoin block header of the block that was used for merged mining the RSK block. + - minimumGasPrice: minimum gas price a transaction should have in order to be included in that block. + - bitcoinMergedMiningHeader: It is the Bitcoin block header of the block that was used for merged mining the RSK block. - bitcoinMergedMiningCoinbaseTransaction: It is the coinbase transaction of the Bitcoin block that was used for merged mining the RSK block. - bitcoinMergedMiningMerkleProof: It is the Merkle proof that links the Bitcoin block's Merkle root with the coinbase transaction. - - hashForMergedMining: It is a hash that is calculated from various fields in the RSK block header. + - hashForMergedMining: It is a hash that is calculated from various fields in the RSK block header. - paidFees: It represents the total amount of fees paid by all transactions included in the block. - cumulativeDifficulty: It represents the total difficulty of the chain up to the current block. - **Example Request:** @@ -415,7 +415,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC "jsonrpc":"2.0", "method":"eth_getBlockByNumber", "params":[ - "0xfcea", + "0xfcea", false ], "id":0 @@ -467,7 +467,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - Block: String, required, either the hexadecimal value of a blockNumber, OR a blockHash, OR one of the following block tags: - latest: the most recent block the client has available. - earliest: the lowest numbered block the client has available. - - pending: A sample next block built by the client on top of latest and containing the set of transactions usually taken from a local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - pending: A sample next block built by the client on top of latest and containing the set of transactions usually taken from a local mempool. Intuitively, you can think of these as blocks that have not been mined yet. - **Example Request:** ```shell curl --location 'https://rpc.testnet.rootstock.io/' \ @@ -478,7 +478,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC "jsonrpc":"2.0", "method":"eth_getCode", "params":[ - "0xebea27d994371cd0cb9896ae4c926bc5221f6317", + "0xebea27d994371cd0cb9896ae4c926bc5221f6317", "latest" ], "id":0 @@ -505,12 +505,12 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - either the hexadecimal value of a blockNumber, OR one of the following block tags: - **latest:** the most recent block the client has available. - **earliest:** the lowest numbered block the client has available. - - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. - `toBlock`: String, optional. - either the hexadecimal value of a blockNumber, OR one of the following block tags: - **latest:** the most recent block the client has available. - **earliest:** the lowest numbered block the client has available. - - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. - _topics_: Array of 32 bytes DATA topics, optional. The required topic to filter. - _Returns:_ - **log objects:** An array of log objects, or an empty array if nothing has changed since last poll. Log objects contain the following keys and their values: @@ -524,8 +524,8 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - **topics:** An array of 0 to 4 indexed log arguments, each 32 bytes. In solidity the first topic is the hash of the signature of the event (e.g. Deposit(address,bytes32,uint256)), except when you declared the event with the anonymous specifier. - Constraints: - You can make `eth_getLogs` requests on any block range with a cap of: - - 10K logs in the response - - OR a 2K block range with no cap on logs in the response + - 10K logs in the response + - OR a 2K block range with no cap on logs in the response - Note that it can be filtered either by blockHash OR (fromBlock and toBlock), but not both. - If `fromBlock`, `toBlock`, or `blockHash` are not specified, the query will return the logs corresponding to the latest block - Example request by blockHash: @@ -547,7 +547,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC { "jsonrpc": "2.0", "id": 0, - "result": [ + "result": [ { { "address": "0x0000000000000000000000000000000001000008", @@ -647,7 +647,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - **Block:** String: required, either the hexadecimal value of a **blockNumber**, OR a blockHash, OR one of the following block tags: - **Latest:** the most recent block the client has available. - **Earliest:** the lowest numbered block the client has available. - - **Pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from a local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - **Pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from a local mempool. Intuitively, you can think of these as blocks that have not been mined yet. - Example request: ```shell curl --location 'https://rpc.testnet.rootstock.io/' \ @@ -658,7 +658,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC "jsonrpc":"2.0", "method":"eth_getStorageAt", "params":[ - "0x295a70b2de5e3953354a6a8344e616ed314d7251","0x0" + "0x295a70b2de5e3953354a6a8344e616ed314d7251","0x0" "latest"], "id":0 }' @@ -740,7 +740,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - _Block_: String: optional, either the hexadecimal value of a `blockNumber`, OR a `blockHash`, OR one of the following block tags: - `latest`: the most recent block the client has available. - `earliest`: the lowest numbered block the client has available. - - `pending`: A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - `pending`: A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. - if not specified, it will return the balance at the latest block available. - **Returns:** - **transaction count:** A hexadecimal equivalent of the integer representing the number of transactions sent from the given address. @@ -859,7 +859,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - `blockNumber`: String, required. The number of the block (in hex) from which the number of transactions is required, OR one of the following block tags: - **latest:** the most recent block the client has available. - **earliest:** the lowest numbered block the client has available. - - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. - **Example** ```shell curl --location 'https://rpc.testnet.rootstock.io/' \ @@ -935,7 +935,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - `blockNumber`: String, required. The number of the block (in hex) from which the number of transactions is required, OR one of the following block tags: - **latest:** the most recent block the client has available. - **earliest:** the lowest numbered block the client has available. - - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. - **index:** String, required. The position number of the transaction (in Hex). - Example: ```shell @@ -1013,7 +1013,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - `blockNumber`: String, required. The number of the block (in hex) from which the number of transactions is required, OR one of the following block tags: - **latest:** the most recent block the client has available. - **earliest:** the lowest numbered block the client has available. - - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. - **Example:** ```shell curl --location 'https://rpc.testnet.rootstock.io/' \ @@ -1069,7 +1069,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - _Params:_ - `transactionData`: Required, the signed transaction data (typically signed with a library, using your private key). Use `eth_getTransactionReceipt` to get the contract address, after the transaction was mined, when you created a contract. - **Example:** - ```shell + ```shell curl --location 'https://rpc.testnet.rootstock.io/' \ --request POST \ --header 'accept: application/json' \ @@ -1082,7 +1082,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC ], "id":0 }' - ``` + ``` - **Example Response:** ```shell { @@ -1095,7 +1095,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - _Method:_ `net_version` - Returns the number of the network, in decimal value. - _Params:_ None -- **Responses:** +- **Responses:** - `31` -> Rootstock Testnet - `30` -> Rootstock Mainnet - **Example:** @@ -1124,7 +1124,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC - Returns the current client version. - _Params:_ None - **Example:** - ```shell + ```shell curl --location 'https://rpc.testnet.rootstock.io/' \ --request POST \ --header 'accept: application/json' \ @@ -1135,7 +1135,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC "params":[], "id":0 }' - ``` + ``` - **Example Response:** ```shell { @@ -1147,7 +1147,7 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC ## web3_sha3 - _Method:_ `web3_sha3` - Returns Keccak-256 (not the standardized SHA3-256) hash of the given data. -- _Params:_ +- _Params:_ - `data`: Required, string: The data in hexadecimal form to convert into a SHA3 hash - **Example:** ```shell @@ -1169,4 +1169,4 @@ Find below a list of methods available on the RPC API. See [how to setup the RPC "id": 0, "result": "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad" } - ``` \ No newline at end of file + ``` diff --git a/docs/03-node-operators/02-merged-mining/02-configure-mining/index.md b/docs/03-node-operators/02-merged-mining/02-configure-mining/index.md index fbf38953..08aaa9e5 100644 --- a/docs/03-node-operators/02-merged-mining/02-configure-mining/index.md +++ b/docs/03-node-operators/02-merged-mining/02-configure-mining/index.md @@ -65,7 +65,7 @@ This can be done in two ways: - Compiling the node with IntelliJ, add to VM options: `-Drsk.conf.file=path/to/your/file.conf` ### Using RocksDB - + :::note[Important Notice] - Starting from [RSKj HOP v4.2.0](https://github.com/rsksmart/rskj/releases/tag/HOP-4.2.0), RocksDB is no longer experimental. As of the most recent version, RocksDB has now been made the default storage library, replacing LevelDB. This change was made to tackle maintainability and performance issues of LevelDB. - Previously, RSKj ran using [LevelDB](https://dbdb.io/db/leveldb) by default, with the option to switch to [RocksDB](http://rocksdb.org/). Now, RocksDB is the default storage option, aiming to enable higher performance within the RSKj nodes. @@ -80,7 +80,7 @@ The `keyvalue.datasource` property in the config may only be either `rocksdb` or `leveldb`. > If you wish to switch between the different storage options, -for example from `leveldb` to `rocksdb` or vice versa, +for example from `leveldb` to `rocksdb` or vice versa, you must **restart** the node with the import option. The following sample command shows how to do this when @@ -135,6 +135,7 @@ To rectify this, change the value of `peer.port` in the config file, or add a `peer.port` flag to the command when you start RSKj. +````mdx-code-block ```shell @@ -146,4 +147,5 @@ or add a `peer.port` flag to the command when you start RSKj. C:\> java -Dpeer.port=50505 -cp co.rsk.Start ``` - \ No newline at end of file + +```` diff --git a/docs/03-node-operators/04-setup/02-installation/docker.md b/docs/03-node-operators/04-setup/02-installation/docker.md index 7acf2e19..19648fd7 100644 --- a/docs/03-node-operators/04-setup/02-installation/docker.md +++ b/docs/03-node-operators/04-setup/02-installation/docker.md @@ -6,7 +6,7 @@ tags: [docker, rootstock, desktop, macOS, rskj, windows, install, rsk, node, how description: "Install RSKj using Docker." --- -Before installing Docker, ensure your system meets the [minimum requirements](/node-operators/setup/requirements/) before installing the Rootstock node (RSKj). +Before installing Docker, ensure your system meets the [minimum requirements](/node-operators/setup/requirements/) before installing the Rootstock node (RSKj). If you already have docker installed. See how to [Install the RSKj node using Docker](#install-rskj-using-docker). ## Install Docker Desktop Client @@ -14,6 +14,7 @@ If you already have docker installed. See how to [Install the RSKj node using Do [Docker Desktop](https://www.docker.com/products/docker-desktop/) provides an easy and fast way for running containerized applications on various operating systems. +````mdx-code-block - [Download](https://www.docker.com/products/docker-desktop) and install @@ -25,6 +26,7 @@ If you already have docker installed. See how to [Install the RSKj node using Do - Note that you will need to use `sudo` for all docker commands, by default. To avoid this [additional steps](https://docs.docker.com/install/linux/linux-postinstall/) are required. +```` :::tip[For Mac M1 / M2 (Apple Chips) using x86 based software] @@ -63,4 +65,4 @@ Regarding the RSKj Docker containers, logs are printed to STDOUT by default, mak ```bash docker run -e RSKJ_LOG_PROPS=DEBUG -``` \ No newline at end of file +``` diff --git a/docs/03-node-operators/04-setup/02-installation/java.md b/docs/03-node-operators/04-setup/02-installation/java.md index a6ac5bc2..ce0b62e1 100644 --- a/docs/03-node-operators/04-setup/02-installation/java.md +++ b/docs/03-node-operators/04-setup/02-installation/java.md @@ -48,6 +48,7 @@ mv ~/Downloads/rskj-core-6.3.1-ARROWHEAD-all.jar SHA256SUMS.asc /Users/{user}/rs ### Run the Node +````mdx-code-block ```shell @@ -60,6 +61,7 @@ mv ~/Downloads/rskj-core-6.3.1-ARROWHEAD-all.jar SHA256SUMS.asc /Users/{user}/rs ``` +```` :::tip[Tip] @@ -70,6 +72,7 @@ Replace `` with the actual path to your JAR file. For exam Instead of the default synchronization, you can use import sync to import a pre-synchronized database from a trusted origin, which is significantly faster. +````mdx-code-block ```shell @@ -82,11 +85,13 @@ Instead of the default synchronization, you can use import sync to import a pre- ``` +```` ### Resolving memory issues **Memory Issues?** If you encounter memory errors and meet the [minimum hardware requirements](/node-operators/setup/requirements/), consider using `-Xmx4G` flag to allocate more memory as shown below: +````mdx-code-block ```shell @@ -99,6 +104,7 @@ Instead of the default synchronization, you can use import sync to import a pre- ``` +```` :::tip[Tip] @@ -109,11 +115,12 @@ Replace `` with your JAR file path. For configuration deta :::info[Info] -After starting the node, if there's no output, this means it's running correctly. +After starting the node, if there's no output, this means it's running correctly. ::: 1. To confirm, open a new console tab (it is important you do not close this tab or interrupt the process) and test the node's RPC server. A sample cURL request: +````mdx-code-block ```shell @@ -126,6 +133,7 @@ After starting the node, if there's no output, this means it's running correctly ``` +```` Output: @@ -135,6 +143,7 @@ Output: 2. To check the block number: +````mdx-code-block ```shell @@ -147,6 +156,7 @@ Output: ``` +```` Output: ```jsx @@ -177,4 +187,4 @@ To change networks on the RSKj node, use the following commands: :::tip[Tip] Replace `` with the actual path to your jar file. For example: `C:/RskjCode/rskj-core-6.3.1-ARROWHEAD-all.jar`. -::: \ No newline at end of file +::: diff --git a/docs/03-node-operators/04-setup/03-configuration/preferences.md b/docs/03-node-operators/04-setup/03-configuration/preferences.md index 356e081d..19f2ee43 100644 --- a/docs/03-node-operators/04-setup/03-configuration/preferences.md +++ b/docs/03-node-operators/04-setup/03-configuration/preferences.md @@ -77,7 +77,7 @@ The `keyvalue.datasource` property in the config may only be either `rocksdb` or `leveldb`. > If you wish to switch between the different storage options, -for example from `leveldb` to `rocksdb` or vice versa, +for example from `leveldb` to `rocksdb` or vice versa, you must **restart** the node with the import option. The following sample command shows how to do this when @@ -133,6 +133,7 @@ To rectify this, change the value of `peer.port` in the config file, or add a `peer.port` flag to the command when you start RSKj. +````mdx-code-block ```shell @@ -144,4 +145,5 @@ or add a `peer.port` flag to the command when you start RSKj. C:\> java -Dpeer.port=50505 -cp co.rsk.Start ``` - \ No newline at end of file + +```` diff --git a/docs/03-node-operators/04-setup/reproducible-build.md b/docs/03-node-operators/04-setup/reproducible-build.md index 40754dc0..1c82bf9f 100644 --- a/docs/03-node-operators/04-setup/reproducible-build.md +++ b/docs/03-node-operators/04-setup/reproducible-build.md @@ -33,6 +33,7 @@ See how to [Setup and Run RSKj using Java](/node-operators/setup/installation/ja Create a ```Dockerfile``` to setup the build environment. +````mdx-code-block ```bash @@ -45,7 +46,7 @@ Create a ```Dockerfile``` to setup the build environment. gpg --keyserver https://secchannel.rsk.co/release.asc --recv-keys 1A92D8942171AFA951A857365DECF4415E3B8FA4 gpg --finger 1A92D8942171AFA951A857365DECF4415E3B8FA4 git clone --single-branch --depth 1 --branch ARROWHEAD-6.3.1 https://github.com/rsksmart/rskj.git /code/rskj - git clone https://github.com/rsksmart/reproducible-builds + git clone https://github.com/rsksmart/reproducible-builds CP /Users/{$USER}/reproducible-builds/rskj/6.3.1-arrowhead/Dockerfile /Users/{$USER}/code/rskj WORKDIR /code/rskj gpg --verify SHA256SUMS.asc @@ -64,20 +65,21 @@ Create a ```Dockerfile``` to setup the build environment. gpg --keyserver https://secchannel.rsk.co/release.asc --recv-keys 1A92D8942171AFA951A857365DECF4415E3B8FA4 gpg --finger 1A92D8942171AFA951A857365DECF4415E3B8FA4 git clone --single-branch --depth 1 --branch ARROWHEAD-6.3.1 https://github.com/rsksmart/rskj.git ./code/rskj - git clone https://github.com/rsksmart/reproducible-builds + git clone https://github.com/rsksmart/reproducible-builds CP /Users/{$USER}/reproducible-builds/rskj/6.3.1-arrowhead/Dockerfile /Users/{$USER}/code/rskj cd /code/rskj gpg --verify SHA256SUMS.asc sha256sum --check SHA256SUMS.asc ./configure.sh - ./gradlew clean build -x test + ./gradlew clean build -x test ``` +```` **Response:** -You should get the following as the final response, +You should get the following as the final response, after running the above steps: ```bash @@ -96,7 +98,7 @@ If you are not familiar with Docker or the ```Dockerfile``` format: what this do To create a reproducible build, run the command below in the same directory: ```bash -docker build -t rskj/6.3.1-arrowhead . +docker build -t rskj/6.3.1-arrowhead . ``` :::danger[Error] @@ -143,4 +145,4 @@ More Resources * [Install Rootstock Node](/node-operators/setup/installation/) * See [Reproducible builds](https://github.com/rsksmart/reproducible-builds/tree/master/rskj) -* Check out the [latest rskj releases](https://github.com/rsksmart/rskj/releases) \ No newline at end of file +* Check out the [latest rskj releases](https://github.com/rsksmart/rskj/releases) diff --git a/docs/03-node-operators/04-setup/security-chain.md b/docs/03-node-operators/04-setup/security-chain.md index 8bb73926..0b54fcc4 100644 --- a/docs/03-node-operators/04-setup/security-chain.md +++ b/docs/03-node-operators/04-setup/security-chain.md @@ -49,12 +49,12 @@ sub rsa4096 2022-05-11 [E] ## Verify the signature of SHA256SUMS.asc -The file`SHA256SUMS.asc` is signed with Rootstock public key and includes SHA256 hashes of the files necessary to start the build process. +The file`SHA256SUMS.asc` is signed with Rootstock public key and includes SHA256 hashes of the files necessary to start the build process. _Note: Ensure to `cd` into the [`rskj`](https://github.com/rsksmart/rskj) directory_ before executing the commands below. ```bash -gpg --verify SHA256SUMS.asc +gpg --verify SHA256SUMS.asc ``` The output should look like this: @@ -78,6 +78,7 @@ The authenticity of the script `configure.sh` is checked using the `sha256sum` c Linux - Windows (bash console) +````mdx-code-block ```bash @@ -90,13 +91,16 @@ Linux - Windows (bash console) ``` +```` ## Run configure script to configure secure environment +````mdx-code-block ```bash ./configure.sh ``` - \ No newline at end of file + +```` diff --git a/docs/03-node-operators/09-troubleshooting/index.md b/docs/03-node-operators/09-troubleshooting/index.md index e8fb7812..c8650b58 100644 --- a/docs/03-node-operators/09-troubleshooting/index.md +++ b/docs/03-node-operators/09-troubleshooting/index.md @@ -10,6 +10,7 @@ This section explains how to solve some known or frequently encountered issues. If what you need is not in this section, **contact us** without hesitation through the [Rootstock Community on Discord](https://rootstock.io/discord). We will be happy to help you! +````mdx-code-block Discovery can't be started @@ -90,7 +91,7 @@ If what you need is not in this section, **contact us** without hesitation throu DbMigrate: Migrate between databases - - This tool allows the user to migrate between different supported databases such as `rocksdb` and `leveldb`. + - This tool allows the user to migrate between different supported databases such as `rocksdb` and `leveldb`. - How to use - To use the `DbMigrate` tool to migrate between databases, we will need a tool class and CLI arguments. - The tool class is: `co.rsk.cli.tools.DbMigrate` @@ -116,5 +117,6 @@ If what you need is not in this section, **contact us** without hesitation throu +```` diff --git a/docs/04-resources/03-faqs/index.md b/docs/04-resources/03-faqs/index.md index a7b4d616..72ec5b20 100644 --- a/docs/04-resources/03-faqs/index.md +++ b/docs/04-resources/03-faqs/index.md @@ -10,6 +10,7 @@ Here are some frequently asked questions about the Rootstock and RIF Platforms. ## About Rootstock +````mdx-code-block What is Rootstock? @@ -71,9 +72,11 @@ Here are some frequently asked questions about the Rootstock and RIF Platforms. +```` ## Rootstock vs Other Platforms +````mdx-code-block How is Rootstock different from Stacks? @@ -98,7 +101,7 @@ Here are some frequently asked questions about the Rootstock and RIF Platforms. How is Rootstock different from drivechains? - - A drivechain is a special sidechain with a specific type of two-way-peg called “hashrate escrow.” This peg mechanism gives most Bitcoin miners control of sidechain withdrawals but incentivizes miners to be honest and not abuse their powers. To achieve this, miners publicly confirm or reject withdrawals during a long period that can last 3 months. During this period, the community can detect cheaters that confirm invalid withdrawals. The peg is secure as long as there are strong long-term incentives for the honest majority of miners not to cheat. Rootstock, on the contrary, does not rely on monetary incentives. It uses a federation of PowHSM devices, and the tamper-proof devices vote on withdrawals. At the same time, each device enforces the same type of “hashrate escrow” but with a much-reduced timeframe of days. Therefore both Drivechains and Rootstock require the miner hashrate to support every withdrawal. + - A drivechain is a special sidechain with a specific type of two-way-peg called “hashrate escrow.” This peg mechanism gives most Bitcoin miners control of sidechain withdrawals but incentivizes miners to be honest and not abuse their powers. To achieve this, miners publicly confirm or reject withdrawals during a long period that can last 3 months. During this period, the community can detect cheaters that confirm invalid withdrawals. The peg is secure as long as there are strong long-term incentives for the honest majority of miners not to cheat. Rootstock, on the contrary, does not rely on monetary incentives. It uses a federation of PowHSM devices, and the tamper-proof devices vote on withdrawals. At the same time, each device enforces the same type of “hashrate escrow” but with a much-reduced timeframe of days. Therefore both Drivechains and Rootstock require the miner hashrate to support every withdrawal. - Drivechains are promising but not currently available as they require a soft-fork in Bitcoin, which has been historically considered controversial and may never be performed. While drivechains may provide greater decentralization, the drivechain peg mechanism has never been tested, so the drivechain peg security is still uncertain. @@ -120,10 +123,12 @@ Here are some frequently asked questions about the Rootstock and RIF Platforms. - +```` + ## Rootstock and RIF Token +````mdx-code-block What is the RIF token, and what is its purpose? @@ -180,9 +185,11 @@ Here are some frequently asked questions about the Rootstock and RIF Platforms. +```` ## Rootstock Features and Functionality +````mdx-code-block What is merged mining, and how does it secure the Rootstock network? @@ -248,10 +255,12 @@ Here are some frequently asked questions about the Rootstock and RIF Platforms. +```` ## Rootstock and RIF Services +````mdx-code-block What is RIF, and what are its goals? @@ -305,10 +314,12 @@ Here are some frequently asked questions about the Rootstock and RIF Platforms. +```` ## Rootstock Security and Scalability +````mdx-code-block What is the PowPeg Federation, and what is its role in the two-way peg? @@ -336,4 +347,5 @@ Here are some frequently asked questions about the Rootstock and RIF Platforms. - The Rootstock two-way peg is a protocol that allows users to transfer bitcoins from the Bitcoin blockchain to the Rootstock blockchain and back, creating a token called RBTC that is pegged to the value of Bitcoin. The Rootstock two-way peg works by locking bitcoins in a multi-signature address on the Bitcoin side and releasing an equivalent amount of RBTC on the Rootstock side. The reverse process is also possible by burning RBTC on the Rootstock side and unlocking bitcoins on the Bitcoin side. A group of reputable organizations controls the multi-signature address called the PowPeg Federation, which uses special hardware devices called PowHSMs to protect private keys and validate transactions. The PowHSMs only sign transactions approved by both the Rootstock and Bitcoin networks using a proof-of-work mechanism. This way, the Rootstock two-way peg ensures high security and decentralization for the peg-in and peg-out transactions. - \ No newline at end of file + +```` diff --git a/docs/04-resources/04-tutorials/index.md b/docs/04-resources/04-tutorials/index.md index 1b8f4a12..7f73af8d 100644 --- a/docs/04-resources/04-tutorials/index.md +++ b/docs/04-resources/04-tutorials/index.md @@ -6,6 +6,7 @@ tags: [rsk, rootstock, beginner, quick starts, advanced, port to rootstock, tuto description: "Tutorials and learning resources" --- +````mdx-code-block - \ No newline at end of file + +```` diff --git a/docs/04-resources/05-port-to-rootstock/ethereum-dapp.md b/docs/04-resources/05-port-to-rootstock/ethereum-dapp.md index 0532adc3..c6001ea5 100644 --- a/docs/04-resources/05-port-to-rootstock/ethereum-dapp.md +++ b/docs/04-resources/05-port-to-rootstock/ethereum-dapp.md @@ -57,9 +57,9 @@ As mentioned earlier, Rootstock generally offers lower gas fees. Developers can ### Prerequisites Before you begin, ensure that you have the following: -- Node.js: +- Node.js: - Make sure you have Node.js installed. If not, you can follow the installation instructions for Windows or MacOS. -- Hardhat: +- Hardhat: - Install Hardhat globally using npm: `npm i -g hardhat` - A basic knowledge of smart contracts and Solidity @@ -103,7 +103,7 @@ Before you begin, ensure that you have the following: ? Do you want to add a .gitignore? (Y/n) › y ``` -6. **Install dependencies with npm**: +6. **Install dependencies with npm**: ```sh ? Do you want to install this sample project's dependencies with npm (hardhat @nomicfoundation/hardhat-toolbox)? (Y/n) › y ``` @@ -142,6 +142,7 @@ To configure the Rootstock networks, you'll need an RPC URL for both mainnet and To get the RPCs, go to the [RPC API dashboard from Rootstock Labs](https://dashboard.rpc.rootstock.io/dashboard) create an account if you don't have one, and get an API key for Rootstock testnet or Rootstock mainnet. +````mdx-code-block ``` @@ -153,10 +154,11 @@ https://rpc.mainnet.rootstock.io/ https://rpc.testnet.rootstock.io/ ``` - + +```` -The next step is to retrieve your private key. If you don't know how to get the private key to your wallet, here's a [tutorial](https://support.metamask.io/managing-my-wallet/secret-recovery-phrase-and-private-keys/how-to-export-an-accounts-private-key/) on [Metamask](https://metamask.io/). +The next step is to retrieve your private key. If you don't know how to get the private key to your wallet, here's a [tutorial](https://support.metamask.io/managing-my-wallet/secret-recovery-phrase-and-private-keys/how-to-export-an-accounts-private-key/) on [Metamask](https://metamask.io/). Also, if you haven't added Rootstock mainnet or testnet to your Metamask Wallet, you can do it by clicking the Add Rootstock or Add Rootstock Testnet buttons in the footer of [mainnet explorer](https://rootstock.blockscout.com/) or [testnet explorer](https://rootstock-testnet.blockscout.com/). @@ -173,7 +175,7 @@ And enter the value after pressing enter. Make sure your TESTNET_RPC_URL value is in this format: `https://rpc.testnet.rootstock.io/API-KEY` -For example, `https://rpc.testnet.rootstock.io/eOQAoxAI7Bt6zZ6blwOdMjQQIzKwSW-W` (Where `eOQAoxAI7Bt6zZ6blwOdMjQQIzKwSW-W` is your API-KEY) +For example, `https://rpc.testnet.rootstock.io/eOQAoxAI7Bt6zZ6blwOdMjQQIzKwSW-W` (Where `eOQAoxAI7Bt6zZ6blwOdMjQQIzKwSW-W` is your API-KEY) ::: @@ -368,8 +370,8 @@ This TypeScript script uses Hardhat Ignition to deploy the `SimpleStorage` contr **4. Confirmation and Deployment** -- Confirm the deployment to the Rootstock testnet by typing “yes.” -- Hardhat Ignition will resume the existing deployment (if any) and execute the deployment process. +- Confirm the deployment to the Rootstock testnet by typing “yes.” +- Hardhat Ignition will resume the existing deployment (if any) and execute the deployment process. - You’ll see a success message indicating that the contract was deployed. ```bash @@ -403,4 +405,4 @@ If you get an error like `IgnitionError: IGN401`, try running the command again. Visit [Rootstock Testnet Explorer](https://explorer.testnet.rootstock.io/). Paste your contract address (`0x3570c42943697702bA582B1ae3093A15D8bc2115`) into the search bar to verify successful deployment. -> If you deployed your contract on [Mainnet Explorer](https://explorer.rootstock.io/). \ No newline at end of file +> If you deployed your contract on [Mainnet Explorer](https://explorer.rootstock.io/). diff --git a/docs/04-resources/05-port-to-rootstock/index.md b/docs/04-resources/05-port-to-rootstock/index.md index c41241c7..77d2ee01 100644 --- a/docs/04-resources/05-port-to-rootstock/index.md +++ b/docs/04-resources/05-port-to-rootstock/index.md @@ -6,6 +6,7 @@ tags: [rsk, rootstock, resources, beginner, quick starts, advanced, port to root description: "Port a dApp from other Chains to Rootstock." --- +````mdx-code-block - \ No newline at end of file + +```` diff --git a/docs/04-resources/06-guides/tokenbridge/faq.md b/docs/04-resources/06-guides/tokenbridge/faq.md index 91cc7c49..16af04a4 100644 --- a/docs/04-resources/06-guides/tokenbridge/faq.md +++ b/docs/04-resources/06-guides/tokenbridge/faq.md @@ -7,13 +7,14 @@ tags: [resources, tokenbridge, blockchain, bridges, tokens, ethereum, rootstock, Find a list of frequently asked questions about the Token Bridge. +````mdx-code-block What is the Token Bridge? - The Token Bridge is an interoperability protocol which allows users to move their own Rootstock or Ethereum ERC20 Tokens between networks in a quick and cost-efficient manner. - The UI is available at: - - Mainnet: [https://dapp.tokenbridge.rootstock.io/](https://dapp.tokenbridge.rootstock.io/) + - Mainnet: [https://dapp.tokenbridge.rootstock.io/](https://dapp.tokenbridge.rootstock.io/) - Testnet: [https://dapp.testnet.bridges.rootstock.io/](https://dapp.testnet.bridges.rootstock.io/) - ![Rootstock-Ethereum Token Bridge](/img/resources/tokenbridge/token-bridge-diagram.jpg) @@ -84,7 +85,7 @@ Find a list of frequently asked questions about the Token Bridge. How many confirmations are required to convert the original tokens to Side tokens and vice-versa? - Confirmations depends on the amount being crossed: - - Small amounts needs 60 confirmations on the Rootstock Mainnet, and 120 confirmations on the Ethereum Mainnet. + - Small amounts needs 60 confirmations on the Rootstock Mainnet, and 120 confirmations on the Ethereum Mainnet. - Medium amounts needs 120 confirmations on the Rootstock Mainnet, and 240 confirmations on the Ethereum Mainnet. - Large amounts needs 2880 confirmations on the Rootstock Mainnet, and 5760 confirmations on the Ethereum Mainnet. - > Note that the values of small, medium, and large amount are defined per token basis, and may change over time. @@ -104,5 +105,6 @@ Find a list of frequently asked questions about the Token Bridge. - +```` + diff --git a/docs/04-resources/06-guides/two-way-peg-app/faqs.md b/docs/04-resources/06-guides/two-way-peg-app/faqs.md index f2b0f28e..3a47687e 100644 --- a/docs/04-resources/06-guides/two-way-peg-app/faqs.md +++ b/docs/04-resources/06-guides/two-way-peg-app/faqs.md @@ -8,6 +8,7 @@ tags: [2 way peg app, powpeg, peg-in, peg-out, bridge, rsk, rootstock] Here, you can find a list of frequently asked questions (FAQs) about the 2 way peg application. +````mdx-code-block 1. What are the requirements to use 2wp-app? @@ -93,24 +94,25 @@ Here, you can find a list of frequently asked questions (FAQs) about the 2 way p 13.After making a native pegout, to which address will I receive my BTCs? > - During the pegout process, the destination address of your BTC is derived from your signature, this enables one to know which address will receive the BTCs. - > - See the [Derivation details page](/resources/guides/two-way-peg-app/pegout/deriving-electrum/) + > - See the [Derivation details page](/resources/guides/two-way-peg-app/pegout/deriving-electrum/) 14.When using **Trezor** i'm receiving the error **Forbidden key path** ? > - The latest versions of Trezor Suite have implemented a security rule to disable its use with non-standard key paths. Therefore, the user must explicitly set **Perform Safety Checks** to **PROMPT** option in **Trezor Suite** in order to use the **Trezor wallet** in the 2wp-app application. - > - If is not enabled you will receive this error ![Trezor Error Key Path](/img/resources/two-way-peg-app/trezor-error.png) - > - This video explains how to enable **Perform Safety Checks** to **PROMPT** on **Trezor Suite** [Enabling Prompt for Key Path](/img/resources/two-way-peg-app/trezor-error-fixed.mp4) + > - If is not enabled you will receive this error ![Trezor Error Key Path](/img/resources/two-way-peg-app/trezor-error.png) + > - This video explains how to enable **Perform Safety Checks** to **PROMPT** on **Trezor Suite** [Enabling Prompt for Key Path](/img/resources/two-way-peg-app/trezor-error-fixed.mp4) +```` ---- ## Next -See [Glossary](/resources/guides/two-way-peg-app/glossary/) section for explanation of terms. \ No newline at end of file +See [Glossary](/resources/guides/two-way-peg-app/glossary/) section for explanation of terms. diff --git a/docs/04-resources/06-guides/two-way-peg-app/glossary.md b/docs/04-resources/06-guides/two-way-peg-app/glossary.md index 1cad8296..561efbe8 100644 --- a/docs/04-resources/06-guides/two-way-peg-app/glossary.md +++ b/docs/04-resources/06-guides/two-way-peg-app/glossary.md @@ -8,6 +8,7 @@ tags: [2 way peg app, powpeg, peg-in, peg-out, bridge, rsk, rootstock] See a list of terms about/related to the 2 way peg app and their meanings. +````mdx-code-block What is the 2 way peg app? @@ -72,7 +73,7 @@ See a list of terms about/related to the 2 way peg app and their meanings. Peg-outs - - A conversion from RBTC to BTC. This locks RBTC on the Rootstock network and releases BTC on the Bitcoin network. + - A conversion from RBTC to BTC. This locks RBTC on the Rootstock network and releases BTC on the Bitcoin network. @@ -117,4 +118,5 @@ See a list of terms about/related to the 2 way peg app and their meanings. - This comprises of the BTC amount + transaction fee selected. - \ No newline at end of file + +```` diff --git a/docs/05-dev-tools/index.md b/docs/05-dev-tools/index.md index 3fb37ef4..8459ce1a 100644 --- a/docs/05-dev-tools/index.md +++ b/docs/05-dev-tools/index.md @@ -6,6 +6,7 @@ tags: [rsk, rootstock, tools, developer tools] description: "Explore a curated selection of smart contract development tools and languages. From the familiar Solidity to Rust or Developer Environments like Hardhat, you'll find everything you need to interact and deploy your smart contracts on Rootstock." --- +````mdx-code-block +```` diff --git a/docs/05-dev-tools/wallets/index.md b/docs/05-dev-tools/wallets/index.md index 317b4e9c..59e1655b 100644 --- a/docs/05-dev-tools/wallets/index.md +++ b/docs/05-dev-tools/wallets/index.md @@ -8,7 +8,9 @@ description: "Learn how to connect to Rootstock with a compatible Wallet" The following wallets support [RBTC](/concepts/rbtc/) and [RIF](/concepts/rif-suite/token) tokens. +````mdx-code-block +```` ## Compatibility Matrix @@ -23,7 +25,7 @@ In the following matrix you can see the different features by wallet. | [Trezor](https://trezor.io/trezor-suite) | ✔ | ✔ | ❌ | | [Metamask](https://metamask.io/download) | ❌ | ❌ | ❌ | Browser, Mobile | | [Portis](https://www.portis.io/) | ✔ | ✔ | ✔ | Desktop | Rootstock (RBTC), Bitcoin | -| [Rabby Wallet](https://rabby.io) | - | - | - | Chrome, Desktop, Mobile | +| [Rabby Wallet](https://rabby.io) | - | - | - | Chrome, Desktop, Mobile | | [Enkrypt](https://www.enkrypt.com/networks/rootstock-wallet/)| - | - | - | Chrome | Rootstock (RBTC), Bitcoin | | [MyCrypto](https://mycrypto.com/) | - | - | - | Desktop | RBTC | | [TaHo](https://taho.xyz) | - | - | - | Chrome | Rootstock (RBTC) @@ -31,7 +33,7 @@ In the following matrix you can see the different features by wallet. | [Bitget](https://web3.bitget.com/en/) | - | - | - | Chrome, Mobile | RBTC | | [SafePal](https://www.safepal.com/en/extension) | - | - | - | Chrome, Mobile | Rootstock (RBTC), Bitcoin | | [Wallby](https://wallby.app/) | - | - | - | Mobile | Rootstock (RBTC), Bitcoin | -| [MathWallet](https://blog.mathwallet.org/?p=1625) | ❌ | ❌ | ❌ | Chrome, Desktop, Mobile | Rootstock (RBTC), Bitcoin | +| [MathWallet](https://blog.mathwallet.org/?p=1625) | ❌ | ❌ | ❌ | Chrome, Desktop, Mobile | Rootstock (RBTC), Bitcoin | | [Block Wallet](https://blockwallet.io/) | - | - | - | Chrome | Rootstock (RBTC) | [MtPelerin Bridge](https://www.mtpelerin.com/bridge-wallet) | - | - | - | Desktop, Mobile | Rootstock (RBTC), Bitcoin | | [Gnosis Safe](https://www.safe.global) | - | - | - | diff --git a/docs/05-dev-tools/wallets/metamask.md b/docs/05-dev-tools/wallets/metamask.md index b939ac4e..90c28da9 100644 --- a/docs/05-dev-tools/wallets/metamask.md +++ b/docs/05-dev-tools/wallets/metamask.md @@ -23,10 +23,10 @@ Visit the [metamask-landing.rifos.org](https://metamask-landing.rifos.org/) tool 2. In the network selector (top right corner), choose Custom RPC.
- +
-3. Fill with these values to connect to Rootstock Mainnet or Testnet +3. Fill with these values to connect to Rootstock Mainnet or Testnet
@@ -112,4 +112,4 @@ A **workaround** for this is to lowercase the addresses after copying them. ::: ## Useful Resources -- [Connect Rootstock to Metamask Programmatically](/resources/tutorials/rootstock-metamask/) \ No newline at end of file +- [Connect Rootstock to Metamask Programmatically](/resources/tutorials/rootstock-metamask/) diff --git a/i18n/es/docusaurus-plugin-content-blog-changelog/2024-07-04-introducing-arrowhead-6-3-0.md b/i18n/es/docusaurus-plugin-content-blog-changelog/2024-07-04-introducing-arrowhead-6-3-0.md new file mode 100644 index 00000000..53c838ba --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog-changelog/2024-07-04-introducing-arrowhead-6-3-0.md @@ -0,0 +1,9 @@ +--- +title: Presentación de Arrowhead 6.3.0 +author: Portainjerto +tags: + - punta de flecha +url: https://blog.rootstock.io/noticia/introducing-arrowhead-6-3-0/ +--- + +La comunidad Rootstock se complace en anunciar el lanzamiento de la última versión del cliente RSKj, que ya está disponible en el [repositorio RSKj GitHub](https://github.com/rsksmart/rskj/releases/tag/ARROWHEAD-6.3.0). Esta actualización se centra principalmente en mejorar la compatibilidad con Ethereum en la interfaz JSON-RPC y en mejorar el rendimiento del nodo. diff --git a/i18n/es/docusaurus-plugin-content-blog-changelog/2024-07-10-introducing-arrowhead-6-3-1.md b/i18n/es/docusaurus-plugin-content-blog-changelog/2024-07-10-introducing-arrowhead-6-3-1.md new file mode 100644 index 00000000..425dccee --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-blog-changelog/2024-07-10-introducing-arrowhead-6-3-1.md @@ -0,0 +1,9 @@ +--- +title: "Presentación de Arrowhead 6.3.1: Lo que debe saber sobre la próxima actualización de la red de parches de Rootstock" +author: Portainjerto +tags: + - liberar +url: https://blog.rootstock.io/noticia/introducing-arrowhead-6-3-1-what-you-need-to-know-about-rootstocks-upcoming-patch-network-upgrade/ +--- + +**Resumen**: La red Rootstock se someterá a una actualización de red de parches en el bloque 6.549.300. Esta actualización obligatoria corrige la interrupción de PowPeg registrada el 24 de junio; los usuarios que se adhieran a estos cambios deberán actualizar sus nodos a la última versión. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/account-based-addresses.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/account-based-addresses.md new file mode 100644 index 00000000..1ac2ff07 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/account-based-addresses.md @@ -0,0 +1,69 @@ +--- +sidebar_label: Direcciones basadas en cuentas +title: Cuentas de portainjertos +sidebar_position: 6 +tags: + - rsk + - portainjertos + - arquitectura + - suma de comprobación + - ruta de derivación + - direcciones de los contratos + - contratos inteligentes +description: EIP-1191 chainId se utiliza en las direcciones Rootstock como suma de comprobación. m/44'/137'/0'/0 es la ruta de derivación utilizada para los monederos compatibles con BIP-44. +--- + +Las direcciones de Rootstock incorporan un identificador de blockchain opcional (también conocido como `chainId`). Si el `chainId` no está presente, se asume que la dirección se refiere a la red principal de Rootstock. + +:::info[Info] +Consulte [direcciones de contrato](/desarrolladores/contratos-inteligentes/direcciones-de-contrato) para ver la lista de direcciones de contrato en Rootstock o [cómo verificar la propiedad de la dirección](/desarrolladores/contratos-inteligentes/verificar-la-propiedad-de-la-dirección/). +::: + +## Cómo obtener una dirección + +Echa un vistazo a las ya [billeteras integradas](/dev-tools/wallets/) en Rootstock. + +## Información sobre la ruta de derivación + +Si utiliza un software de monedero +compatible con +[BIP-44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki "Jerarquía multicuenta para monederos deterministas"), deberá especificar una ruta de derivación. + +```text +Mainnet: m/44'/137'/0'/0/N +Testnet: m/44'/37310'/0'/0/N +``` + +- El primer nivel de la jerarquía corresponde al _propósito_. + Siempre es "44", según la especificación BIP44. +- El segundo nivel de la jerarquía corresponde al _tipo de moneda registrada_. + - Para Rootstock Mainnet, debería ser `137'`, según la especificación + [SLIP-44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md "Registered coin types for BIP-0044") + . + - Para Rootstock Testnet, debe ser `37310'`, según la especificación + [RSKIP-57](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP57.md "Derivation Path for Hierarchical Deterministic Wallets") + . +- El último nivel de la jerarquía es para _índice_: Las direcciones se numeran a partir del índice 0 de forma secuencialmente creciente. Este número se utiliza como índice hijo en [BIP32 derivation](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#specification-key-derivation "Hierarchical Deterministic Wallets - Key Derivation"). En este nivel se utiliza la derivación pública. + +## Suma de comprobación + +Rootstock implementa [EIP-1191](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1191.md) para proteger a los usuarios de la pérdida de fondos por mezclar direcciones de diferentes redes basadas en Ethereum. + +[En este documento](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1191.md), se explica cómo aplicar la suma de comprobación y validar una dirección. Este EIP también es compatible con Web3 y los monederos físicos. + +## ChainId + +Para evitar un ataque de repetición mediante el uso de una transacción ya firmada, originalmente emitida en la "red A", y posteriormente reproducida en la "red B", las redes basadas en EVM utilizan `chainId` como parte de las propiedades de la transacción. +Todos los `chainId` pueden encontrarse en [chainid.network](https://chainid.network/). + +``` +Red principal de portainjertos: 30 +Rootstock Testnet: 31 +``` + +Para más información, véase [EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md#user-content-list-of-chain-ids). + +Recomendamos encarecidamente lo siguiente: + +1. Añada el `chainId` en la integración de Rootstock (y cada vez que integre blockchains basados en EVM) +2. Utilice una cuenta diferente para guardar el valor de cada blockchain (no comparta la misma cuenta entre Rootstock, ETH y otros). diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/fundamentals/index.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/fundamentals/index.md new file mode 100644 index 00000000..2786a6b1 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/fundamentals/index.md @@ -0,0 +1,60 @@ +--- +sidebar_label: Fundamentos de los portainjertos +sidebar_position: 2 +title: Fundamentos de los portainjertos +tags: + - rsk + - portainjertos + - principiante + - conceptos +description: Rootstock es la primera y más duradera cadena lateral de Bitcoin. Es la única solución de capa 2 que combina la seguridad de la prueba de trabajo de Bitcoin con las capacidades de contrato inteligente de Ethereum. +--- + +## ¿Qué es el portainjertos? + +Rootstock es la primera y más duradera cadena lateral de Bitcoin. Es la única solución de capa 2 que combina la seguridad de la prueba de trabajo de Bitcoin con las capacidades de contrato inteligente de Ethereum. La plataforma es de código abierto, compatible con EVM y asegurada por más del 60% de la potencia de hashing de Bitcoin, lo que la convierte en la puerta de entrada a un vibrante ecosistema de dApps que sigue evolucionando para convertirse en totalmente fiable. + +Véase la [Pila de rizomas](/conceptos/fundamentos/pila/). + +## ¿Qué relación tiene Rootstock con bitcoin? + +### Minería fusionada con Bitcoin + +El primer punto de contacto es la minería. + +Los mineros de bitcoin hacen lo que se conoce como +[merged mining](/node-operators/merged-mining/), +asegurando ambas redes con la misma infraestructura y consumo energético. + +Crean bloques en la red bitcoin cada 10 minutos, +incluida la transferencia de bitcoin desde diferentes direcciones +y en el proceso crean nuevos bitcoins. + +En Rootstock, los bloques se crean cada 30 segundos, +para asegurar la ejecución de contratos inteligentes. +Esto no acuña nuevas monedas en el proceso, +pero sí obtiene una recompensa de la minería fusionada. + +> Consulte [https://rootstock.io/mine-btc-with-rootstock/](https://rootstock.io/mine-btc-with-rootstock/) para obtener más información sobre la minería. + +### Powpeg con Bitcoin + +El segundo punto de contacto es el +[Powpeg](/conceptos/powpeg/), +también conocido como el puente. + +Este componente conecta ambas redes para permitir a +la transferencia de bitcoins a Rootstock, +permitiendo así a los desarrolladores interactuar con contratos inteligentes. +Pagan el gas utilizando el mismo bitcoin, el bitcoin inteligente. + +Para ello, se envían bitcoin a una dirección especial, +, donde quedan bloqueados en la red bitcoin. +A continuación, en la misma dirección de la red Rootstock, +, se libera ese mismo bitcoin al usuario +para que lo utilice en la red Rootstock. +Esto se denomina "peg-in". + +Puedes hacer la operación inversa llamada peg-out, +enviando tu bitcoin a una dirección especial en la red Rootstock, +y recibiendo tu bitcoin de vuelta en la red bitcoin. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/fundamentals/stack/index.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/fundamentals/stack/index.md new file mode 100644 index 00000000..38d625b5 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/fundamentals/stack/index.md @@ -0,0 +1,49 @@ +--- +section_label: La pila +title: Pila de portainjertos +sidebar_label: La pila +sidebar_position: 200 +tags: + - rsk + - portainjertos + - pila + - arquitectura +description: Descubra cómo Rootstock combina la seguridad de Bitcoin PoW con la funcionalidad de contratos inteligentes de Ethereum para crear dApps en Bitcoin y también cómo las herramientas y tecnologías de código abierto de RIF están diseñadas para agilizar e incentivar el desarrollo en Bitcoin. +--- + +La máquina virtual Rootstock (RVM) es el núcleo de la plataforma de Contratos Inteligentes. Todos los nodos completos de la red ejecutan contratos inteligentes. El resultado de la ejecución de un contrato inteligente puede ser el procesamiento de mensajes entre contratos, la creación de transacciones monetarias y el cambio del estado de la memoria persistente del contrato. El RVM es compatible con EVM a nivel de op-code, permitiendo que los contratos de Ethereum se ejecuten sin problemas en Rootstock. + +Actualmente, la VM se ejecuta mediante interpretación. En una futura actualización de la red, la comunidad Rootstock pretende mejorar sustancialmente el rendimiento de la máquina virtual. Una propuesta es emular la EVM reorientando dinámicamente los opcodes de la EVM a un subconjunto de bytecode similar a Java, y una VM similar a Java reforzada en seguridad y restringida en memoria se convertirá en la nueva VM (RVM2). Esto puede llevar la ejecución de código Rootstock a un rendimiento cercano al del código nativo. + +## Características principales: + +- Máquina virtual independiente, altamente compatible con EVM a nivel de opcode. +- Ejecute DApps de Ethereum con la seguridad de la red Bitcoin +- Canal de mejora del rendimiento documentado en numerosos RSKIP creados por la comunidad Rootstock + - Véanse las [Propuestas de mejora de portainjertos](https://github.com/rsksmart/RSKIPs). + +Pila tecnológica del patrón - Alto nivel](/img/concepts/rootstock-tech-stack.svg) + +
+
+
+
+

Bitcoin

BTC

+
+

Es un almacén y transferencia de valor. +La blockchain es segura porque los mineros +con elevados costes de infraestructura y energía +crean los nuevos bloques que se añaden a la blockchain cada 10 minutos. +Cuanta más potencia de hashing proporcionen, más segura será la red.

+
+
+

Portainjerto

RBTC

+

Es la primera plataforma de contratos inteligentes de código abierto + impulsada por la red bitcoin. + El objetivo de Rootstock es añadir valor y funcionalidad al ecosistema bitcoin de + permitiendo contratos inteligentes, + pagos casi instantáneos y una mayor escalabilidad.

+

El [Smart Bitcoin (RBTC)](/concepts/rbtc/) es la moneda nativa de Rootstock y se utiliza para pagar el gas necesario para la ejecución de las transacciones. Está vinculado 1:1 con Bitcoin, lo que significa que en Rootstock hay exactamente 21M de RBTC. Un [Powpeg](/conceptos/powpeg/) permite la [transferencia de bitcoins](/conceptos/rbtc/conversión/) de la blockchain de Bitcoin a la blockchain de Rootstock y viceversa.

+
+
+
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/index.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/index.md index 42e65abb..83f46307 100644 --- a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/index.md +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/index.md @@ -1,44 +1,50 @@ --- sidebar_position: 1 -title: Descripción general de conceptos -sidebar_label: Overview -tags: [rsk, rootstock, concepts, glossary, resources] -description: "This section of the documentation covers the core concepts about the Rootstock blockchain. Working with Rootstock requires an understanding of blockchain technology, bitcoin and smart contracts." +title: Conceptos generales +sidebar_label: Visión general +tags: + - rsk + - portainjertos + - conceptos + - glosario + - recursos +description: Esta sección de la documentación cubre los conceptos básicos sobre la blockchain de Rootstock. Para trabajar con Rootstock es necesario conocer la tecnología blockchain, bitcoin y los contratos inteligentes. --- -Rootstock es la primera y más duradera cadena lateral de Bitcoin. Es la única solución de capa 2 que combina la seguridad de la prueba de trabajo de Bitcoin con las capacidades de contrato inteligente de Ethereum. La plataforma es de código abierto, compatible con EVM y está protegida por más del 60 % del poder de hash de Bitcoin. Este sólido modelo de seguridad permite a los desarrolladores crear aplicaciones descentralizadas innovadoras y sin necesidad de confiar en ellas dentro de un ecosistema próspero. +Rootstock es la primera y más duradera cadena lateral de Bitcoin. Es la única solución de capa 2 que combina la seguridad de la prueba de trabajo de Bitcoin con las capacidades de contrato inteligente de Ethereum. La plataforma es de código abierto, compatible con EVM y protegida por más del 60% de la potencia de hash de Bitcoin. Este sólido modelo de seguridad permite a los desarrolladores crear aplicaciones digitales innovadoras y fiables dentro de un próspero ecosistema. -Esta sección le proporciona los conocimientos fundamentales necesarios para navegar por la cadena de bloques de Rootstock. La familiaridad con la tecnología de la cadena de bloques, Bitcoin y los contratos inteligentes le resultará beneficiosa a medida que navegue más profundamente. -## Navigating Core Concepts +Esta sección le proporciona los conocimientos fundamentales necesarios para navegar por la blockchain de Rootstock. Familiarizarse con la tecnología blockchain, Bitcoin y los contratos inteligentes será beneficioso a medida que profundice en su navegación. -| Resource | Description | -| ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | -| [Rootstock Blockchain Overview](/concepts/fundamentals/) | Gain a comprehensive understanding of the Rootstock platform. | -| [Rootstock Stack](/concepts/fundamentals/stack/) | Learn about how Rootstock combines the security of Bitcoin PoW with Ethereum's smart contract functionality.| -| [RBTC Token](/concepts/rbtc/) | The RBTC token fuels transactions on the Rootstock network. Converting BTC to RBTC is straightforward using various methods. Visit the RBTC section for a comprehensive list of exchanges and applications facilitating RBTC acquisition. Visit the [RBTC section](https://rootstock.io/rbtc/) for a list of exchanges and apps to get RBTC.| -| [RIF Suite](/concepts/rif-suite/) | Learn about the Rootstock Infrastructure Framework, a comprehensive set of Open-source tools and technologies designed to streamline and incentivize development on Bitcoin.| -| [Rootstock Security](/concepts/powpeg/security-model/) | The Rootstock platform uses a security mechanism called the [Powpeg](/concepts/powpeg/), it is based on a layered security model, called “defence-in-depth”.| -| [Powpeg HSM Firmware](/concepts/powpeg/hsm-firmware-attestation/) | Learn how to verify Powpeg nodes using the HSM Firmware Attestation. | -| [Account Based Addresses](/concepts/account-based-addresses/) | EIP-1191 chainId is used in Rootstock addresses as a checksum. m/44'/137'/0'/0 is the derivation path used for BIP-44 compatible wallets. | +## Navegar por los conceptos básicos -## Next Steps +| Recursos | Descripción | +| -------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Visión general de [Rootstock Blockchain](/conceptos/fundamentos/) | Conozca a fondo la plataforma Rootstock. | +| [Pila de rizomas](/conceptos/fundamentos/pila/) | Descubra cómo Rootstock combina la seguridad de Bitcoin PoW con la funcionalidad de contratos inteligentes de Ethereum. | +| [Ficha RBTC](/conceptos/rbtc/) | El token RBTC alimenta las transacciones en la red Rootstock. Convertir BTC en RBTC es sencillo utilizando varios métodos. Visite la sección RBTC para obtener una lista completa de intercambios y aplicaciones que facilitan la adquisición de RBTC. Visite la [sección RBTC](https://rootstock.io/rbtc/) para obtener una lista de intercambios y aplicaciones para obtener RBTC. | +| [RIF Suite](/conceptos/rif-suite/) | Conozca el Marco de Infraestructura Rootstock, un amplio conjunto de herramientas y tecnologías de código abierto diseñadas para agilizar e incentivar el desarrollo en Bitcoin. | +| [Rootstock Security](/conceptos/powpeg/seguridad-modelo/) | La plataforma Rootstock utiliza un mecanismo de seguridad denominado [Powpeg](/conceptos/powpeg/), basado en un modelo de seguridad por capas denominado "defensa en profundidad". | +| [Firmware Powpeg HSM](/concepts/powpeg/hsm-firmware-attestation/) | Aprenda a verificar los nodos Powpeg utilizando el HSM Firmware Attestation. | +| [Direcciones basadas en cuentas](/concepts/account-based-addresses/) | EIP-1191 chainId se utiliza en las direcciones Rootstock como suma de comprobación. m/44'/137'/0'/0 es la ruta de derivación utilizada para los monederos compatibles con BIP-44. | -Ready to embark on your Rootstock development journey? Explore these sections tailored to your specific interests: +## Próximos pasos -### Developers +¿Está preparado para embarcarse en su viaje de desarrollo del Rootstock? Explore estas secciones adaptadas a sus intereses específicos: -The [Developers](/developers/) section provides all the neccessary guides and information for building secure and scalable dApps on Bitcoin with Rootstock. Leverage your existing knowledge of Solidity and tools like Rust, Hardhat, and Wagmi to deploy and scale your dApps on the pioneering layer 2 solution that combines the best of Bitcoin security and Ethereum Smart Contract capabilities. +### Desarrolladores -### Node Operators +La sección [Developers](/developers/) proporciona todas las guías e información necesarias para construir dApps seguras y escalables en Bitcoin con Rootstock. Aproveche su conocimiento existente de Solidity y herramientas como Rust, Hardhat y Wagmi para desplegar y escalar sus dApps en la solución pionera de capa 2 que combina lo mejor de la seguridad de Bitcoin y las capacidades de Ethereum Smart Contract. -Rootstock's [Merged mining](https://rootstock.io/mine-btc-with-rootstock/) offers bitcoin miners an additional revenue stream at no additional cost by using the same mining infrastructure and work to secure the Rootstock sidechain. +### Operadores de nodo -The [Node Operators](/node-operators/) section caters specifically to node miners and developers interested in running and managing a Rootstock node. +La [minería fusionada] de Rootstock (https://rootstock.io/mine-btc-with-rootstock/) ofrece a los mineros de bitcoins una fuente de ingresos adicional sin coste adicional utilizando la misma infraestructura minera y trabajando para asegurar la cadena lateral de Rootstock. -### Developer Tools +La sección [Operadores de nodos](/node-operators/) está dirigida específicamente a mineros de nodos y desarrolladores interesados en ejecutar y gestionar un nodo Rootstock. -The [tools](/dev-tools/) section curates all the essential developer tools available on Rootstock. Find comprehensive resources on tool configuration, usage guides, reference materials, and informative tutorials. +### Herramientas para desarrolladores -### Resources +La sección [tools](/dev-tools/) recoge todas las herramientas esenciales para desarrolladores disponibles en Rootstock. Encuentra recursos completos sobre configuración de herramientas, guías de uso, materiales de referencia y tutoriales informativos. -Expand your knowledge base with the [comprehensive Resources](/resources/) section. Explore tutorials, courses, FAQs, and valuable information on contributing to the Rootstock ecosystem. +### Recursos + +Amplíe su base de conocimientos con la sección [Recursos completos](/resources/). Explore tutoriales, cursos, preguntas frecuentes e información valiosa sobre cómo contribuir al ecosistema Rootstock. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/merged-mining/index.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/merged-mining/index.md new file mode 100644 index 00000000..159529b6 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/merged-mining/index.md @@ -0,0 +1,42 @@ +--- +sidebar_position: 7 +title: ¿Qué es la minería combinada? +sidebar_label: Minería fusionada +tags: + - rsk + - portainjertos + - conceptos + - minería fusionada +description: Cómo funciona la minería de fusión Rootstock con Bitcoin, y sus beneficios. +--- + +La [minería fusionada](https://rootstock.io/mine-btc-with-rootstock/) es el proceso que permite minar la blockchain de Rootstock simultáneamente con la blockchain de Bitcoin. Esto puede hacerse porque ambas cadenas utilizan el mismo algoritmo de prueba de trabajo (PoW), doble SHA-256. + +[Comenzar](/node-operators/merged-mining/getting-started/) + +## Cómo funciona + +Los pools de minería de Bitcoin incluyen una referencia al bloque de Rootstock en cada trabajo de minería que entregan a los mineros. +Cada vez que los mineros encuentran una solución, se compara con las dificultades de ambas redes (Bitcoin y Rootstock), lo que arroja tres posibles resultados: + +- La solución satisface la dificultad de la red Bitcoin. Por lo tanto, un bloque es ensamblado y enviado a la red. La referencia de minería combinada de Rootstock será incluida e ignorada por la red Bitcoin. Dado que la dificultad de red de Rootstock es menor que la de Bitcoin, esta solución también funcionará para Rootstock y podrá ser enviada a la red. +- La solución no satisface la dificultad de la red Bitcoin, pero sí la de la red Rootstock. En consecuencia, la solución se enviará a la red Rootstock, pero no a la red Bitcoin. +- La solución sólo satisface la dificultad del pool, que es muchas veces inferior a la dificultad de red de Bitcoin o Rootstock, y no se somete a ninguna red. + +La solución enviada a la red permite al nodo construir una prueba SPV. Si la prueba es válida, se incluye como parte del bloque que se enviará a la red. + +
+ +
+ +## ¿Cuáles son las ventajas? + +Los mineros obtienen un alto porcentaje de las comisiones por transacción del bloque de Rootstock que minan. Este proceso de minería se realiza con la misma potencia de hashing utilizada en la minería de Bitcoin, y no tiene ningún coste o impacto adicional. + +## ¿Cuál es la potencia de hashing de la red Rootstock actual? + +Puede ver la potencia de hashing de la red Rootstock en el [Sitio web de estadísticas de Rootstock](https://stats.rootstock.io). + +## Detalles de implantación de los grupos de software de minería + +Consulte la [Guía de implantación inicial] (/node-operators/merged-mining/getting-started/). diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/powpeg/hsm-firmware-attestation.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/powpeg/hsm-firmware-attestation.md new file mode 100644 index 00000000..2e48008e --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/powpeg/hsm-firmware-attestation.md @@ -0,0 +1,41 @@ +--- +title: Certificación del firmware del HSM de Powpeg +sidebar_position: 250 +sidebar_label: Verificar los nodos Powpeg +tags: + - rsk + - portainjertos + - rbtc + - btc + - peg + - powpeg + - hsm +description: Aprenda a verificar los nodos Powpeg utilizando el HSM Firmware Attestation. +render_features: powpeg-hsm-attestation-frame +--- + +Para verificar los nodos Powpeg, siga el proceso de atestación del firmware del HSM siguiendo los pasos que se indican a continuación. Consulte el [LÉAME de atestación](https://github.com/rsksmart/rsk-powhsm/blob/2.3.5/docs/attestation.md). + +### Certificación del firmware de Powpeg HSM - Sovryn + + + +### Certificación del firmware HSM de Powpeg - pNetwork + + + +### Preguntas frecuentes + +```mdx-code-block + + + ¿Cuál es el esquema multisig para el powHSM? Es un multisig M de N. +¿Qué es M y qué es N? + + > - R: La mejor forma de obtener esta información es consultando directamente al Bridge, ya que el número de miembros del PowPeg puede cambiar tras un cambio de composición del PowPeg. + > - Puede utilizar los siguientes métodos para consultar el puente: `getFederationSize`, `getFederationThreshold`. + > - Por consenso, el número necesario de firmantes (M) será siempre la mitad más uno del número total de pegnatarios `M = N / 2 + 1`. Consulte la información sobre firmantes y atestación en [PowPeg HSM Firmware Attestation](#powpeg-hsm-firmware-attestation---sovryn). + + + +``` diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/powpeg/index.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/powpeg/index.md new file mode 100644 index 00000000..5a4e2468 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/powpeg/index.md @@ -0,0 +1,111 @@ +--- +title: Construir la clavija Bitcoin más segura, sin permisos y sin censura +sidebar_position: 4 +sidebar_label: Powpeg +tags: + - rsk + - portainjertos + - rbtc + - btc + - arquitectura + - powpeg + - Clavija de 2 vías +description: Transfiera BTC a RBTC, y RBTC a BTC a través del Powpeg. +render_features: powpeg-hsm-attestation-frame +--- + +El protocolo peg bidireccional de Rootstock, llamado "el **Powpeg**", ha madurado desde sus inicios en 2018 como federación hasta incluir ahora muchas cualidades descentralizadas. El nuevo Powpeg de Rootstock protege las claves privadas almacenadas en PowHSM de propósito especial basadas en elementos seguros (SE) a prueba de manipulaciones. Cada PowHSM ejecuta un nodo Rootstock en modo SPV, por lo que las firmas sólo pueden comandarse mediante pruebas de trabajo acumulativas en cadena. La seguridad se establece en el Powpeg mediante la simplicidad de un diseño en capas que denominamos defensa en profundidad. + +:::note\[Info] + +- La aplicación 2 Way Peg está disponible en [Testnet](https://app.2wp.testnet.rootstock.io/) y [Mainnet](https://app.2wp.rootstock.io/). +- Para obtener información general sobre el diseño y la arquitectura, cómo realizar una transacción peg-in utilizando Ledger y Trezor, preguntas frecuentes y operaciones avanzadas que puede realizar en la aplicación 2 way peg, consulte la [Guía del usuario de la aplicación 2 way peg](/resources/guides/two-way-peg-app/). +- Obtenga información sobre los firmantes y la atestación en la sección [Powpeg HSM Firmware Attestation](/concepts/powpeg/hsm-firmware-attestation). + +::: + +## Historia del Powpeg + +Dos cadenas de bloques con formatos de bloque distintos pueden comunicarse de forma totalmente descentralizada si cada una puede evaluar las reglas de consenso de la otra cadena y si los mensajes entre cadenas no se censuran durante largos periodos de tiempo. Actualmente, sólo las plataformas con contratos inteligentes "Turing-completos" pueden evaluar las reglas de consenso de otras cadenas de bloques. Bitcoin, para bien o para mal, carece de la capacidad de desbloquear monedas sobre predicados arbitrarios. Por lo tanto, cuando se creó Rootstock, tuvo que utilizar la única tecnología existente en Bitcoin para distribuir confianza entre las partes: las multifirmas. Con una multi-firma es posible dar a un grupo de notarios la tarea de proteger bitcoins bloqueados, tolerando una cierta cantidad de partes maliciosas, hackeadas o no disponibles. + +Cuando se minó el bloque génesis de Rootstock, nació la Federación Rootstock, un conjunto autónomo de funcionarios cuyo objetivo es proteger la multifirma. La federación estaba controlada por el Puente Rootstock, un contrato inteligente imparable que se ejecuta en Rootstock, y ha funcionado con éxito desde su creación. En 2020 la comunidad Rootstock decidió que era hora de que la clavija Rootstock creciera, tanto en seguridad como en resistencia a la censura, evolucionando de un sistema federado al Powpeg. El Powpeg es un sistema peg único de 2 vías que asegura los bitcoins bloqueados con el mismo hashrate de Bitcoin que establece el consenso. El conjunto de funcionarios sigue existiendo, pero su papel consiste principalmente en mantener su hardware y nodos conectados y vivos en todo momento; no controlan directamente las claves privadas multisig de Bitcoin. Véase [PowPeg HSM Firmware Attestation](/concepts/powpeg/hsm-firmware-attestation) + +## El Powpeg en Rootstock + +La estrategia de los investigadores y desarrolladores de Rootstock a la hora de diseñar el Powpeg difiere de la adoptada por otros equipos que han construido protocolos peg bidireccionales. El Powpeg de Rootstock se basa en un modelo de seguridad por capas, una práctica que denominamos "**defensa en profundidad**". La mayoría de las demás clavijas se basan en un único protocolo criptográfico global que resuelve de forma intrincada un problema de custodia multipartita. Estos complejos protocolos criptográficos son delicados y muy pocas entidades pueden auditarlos a fondo. A menudo, este tipo de protocolos se ven comprometidos, lo que provoca una pérdida repentina de seguridad para los usuarios. + +Otros diseños recientes de pegs de 2 vías se centran en incentivos criptoeconómicos que aprovechan la alta colateralización en un nuevo token. Sin embargo, utilizar un token diferente para la funcionalidad central de la cadena lateral no está alineado con los valores de Bitcoin. El puente Powpeg de Rootstock, en cambio, se basa en múltiples defensas, o capas, con cada capa relativamente sencilla de entender y probar. Este enfoque de defensa en profundidad es lo que ha permitido a Rootstock crecer desde su génesis hasta el estado actual sin mayores problemas y sin tiempos de inactividad. Dado que no hay garantías, los miembros del Powpeg de Rootstock están incentivados a participar recibiendo una pequeña parte de las comisiones por transacciones de Rootstock que se les canaliza automáticamente. Como se ha visto en el ecosistema Ethereum, las tasas de transacción pueden llegar a proporcionar unos ingresos sostenidos a los mineros y, en ocasiones, [incluso superiores](https://coinmetrics.io/ethereums-defi-evolution-how-defi-is-fueling-ethereums-growth/) a la subvención del blockchain. + +## Funcionarios de Powpeg + +Los funcionarios que participan en el PowPeg de Rootstock mantienen activo un hardware especializado denominado **PowHSM** y conectado a tipos especiales de nodos completos de Rootstock (el "Nodo Powpeg"). Un PowHSM es un dispositivo externo a prueba de manipulaciones que crea y protege una de las claves privadas necesarias para el protocolo multifirma de Bitcoin, firmando únicamente transacciones cuya validez ha sido probada por suficiente trabajo acumulado. El nodo Powpeg está diseñado para tener la máxima conectividad y comunicar información sobre la blockchain del Rootstock, en concreto el trabajo acumulado, al PowHSM. + +El papel del funcionario es garantizar que el PowHSM firme únicamente transacciones válidas con varias firmas, auditando los cambios en el PowHSM, el nodo Powpeg y la comunicación entre ellos. Los propios funcionarios no participan activamente en la firma de las transacciones en modo alguno, y no participan en la producción de bloques en la blockchain de Rootstock. + +## Mineros fusionados y el Monitor Armadillo + +Una gran parte de los mineros de Bitcoin participan en la minería fusionada de Rootstock, proporcionando las propiedades de persistencia y liveness blockchain necesarias para asegurar eficazmente la red Rootstock. El papel de los mineros fusionados en el protocolo Powpeg es la capa más grande y crucial del enfoque de defensa en profundidad de Rootstock para asegurar el puente entre Rootstock y Bitcoin. Los funcionarios confían en la estabilidad de los mineros fusionados para garantizar que las transacciones válidas con múltiples firmas se firmen y validen de forma segura y oportuna. + +## Los agentes económicos y el contrato puente + +Los agentes económicos, como los comerciantes y las bolsas, interactúan con el sistema Rootstock 2-way peg enviando y recibiendo transacciones peg-in y peg-out (descritas con más detalle a continuación) al contrato inteligente Bridge a través de la red Rootstock. El Bridge es un contrato inteligente precompilado que vive en la blockchain de Rootstock. La función del Bridge es mantener una vista actualizada del blockchain de Bitcoin, verificar las solicitudes de peg-in y ordenar los peg-outs. Para conseguir esta funcionalidad, el contrato Bridge gestiona un monedero Bitcoin en modo SPV ([Simple Payment Verification](https://en.bitcoinwiki.org/wiki/Simplified_Payment_Verification)). En este modo, las transacciones se confirman mediante cabeceras de bloque y las cabeceras de bloque se validan mínimamente, pero la validación incluye la prueba de trabajo esperada. Estas validaciones aseguran que el monedero Bridge sigue la cadena Bitcoin que tiene el mayor trabajo en cadena, pero no comprueba que la cadena sea válida. + +Normalmente la cadena con mayor trabajo en cadena es la mejor cadena de la red. En la historia de Bitcoin sólo hubo una [bifurcación no intencionada de la red](https://bitcoinmagazine.com/articles/bitcoin-network-shaken-by-blockchain-fork-1363144448) en la que una rama no era válida según las reglas de consenso preestablecidas. La longitud de la bifurcación fue de 24 bloques. Por lo tanto, para prevenir bifurcaciones inválidas intencionadas o no, el Puente está diseñado para esperar 100 confirmaciones antes de confirmar una transacción peg-in. + +## Peg-in/Peg-out y otras propiedades del portainjertos Powpeg + +Utilizamos los términos ya estandarizados peg-in para el proceso que transfiere bitcoins a la cadena lateral, y peg-out para el proceso que los devuelve a Bitcoin. Realizar un peg-in es tan fácil como enviar los bitcoins a la dirección de Powpeg e informar a Bridge de la transacción de Bitcoin. Los funcionarios de Powpeg prestan un servicio de "torre de vigilancia" en nombre de los usuarios e informan a Bridge de cualquier "peg-in". + +El Rootstock Powpeg es un protocolo de migración de activos y no puede abortar un peg-in en caso de retrasos en la red. La imposibilidad de abortar un peg-in en caso de retrasos en la red es lo que generalmente distingue a los protocolos de migración de activos de los protocolos de intercambio. En los protocolos de intercambio, siempre existe el riesgo de que la contraparte no desbloquee los fondos, y el usuario se ve obligado a informar de este fallo en un plazo limitado. Sólo en un caso especial Rootstock reembolsa los bitcoins de una operación de peg-in, y es cuando se supera un límite, que aumenta gradualmente con el tiempo. + +Técnicamente, el Powpeg de Rootstock es un peg híbrido. Los peg-ins funcionan de forma totalmente descentralizada utilizando pruebas SPV y los miembros del Powpeg actúan únicamente como torres de vigilancia para garantizar que los depósitos de bitcoins se comunican correctamente a Rootstock. El usuario que emite la transacción puede informar a Rootstock si los miembros del Powpeg no lo hacen, suponiendo que, en el peor de los casos, el usuario esté finalmente en línea para informar a Rootstock de la transacción. Dado que Rootstock asume que un usuario es el emisor y el receptor de una transacción de clavija bidireccional, se recomienda encarecidamente que los usuarios informen a la red Rootstock. + +Para realizar peg-outs, el Puente acepta solicitudes de cuentas Rootstock y, tras miles de bloques de confirmación, el Puente construye una transacción de peg-out de Bitcoin ordenando a los PowHSM que firmen esta transacción. El puente selecciona las entradas de transacción (o UTXOs) que se incluirán en las transacciones de peg-out, evitando la censura selectiva de UTXOs de cualquier tipo. El puente también coordina y aplica retrasos forzados a todas las operaciones de tesorería necesarias cuando cambia la composición del Powpeg. Por último, el Puente sirve de Oráculo para exponer la blockchain de Bitcoin a los contratos inteligentes de Rootstock. Los peg-outs de Rootstock dependen de la participación de los PowHSM y de la colaboración de la mayoría de los miembros del Powpeg, ya que los PowHSM deben firmar cada transacción de peg-out. Asumiendo la seguridad práctica proporcionada por las PowHSM, los acuerdos de devolución de Powpeg tampoco son fiables. + +## Raíz Powpeg Seguridad + +El Powpeg se está convirtiendo en uno de los sistemas multifirma más seguros que existen. Técnicamente, la seguridad del Powpeg se basa en varias estrategias concurrentes: Defensa en profundidad, transparencia de la coordinación y atestación pública, pero la seguridad de una clavija no sólo depende de sus características técnicas. La seguridad en el mundo real debe analizarse desde varios puntos de vista: técnico, operativo y de reputación. A continuación nos centraremos en las decisiones de diseño técnico de Powpeg. + +## Defensa en profundidad + +La defensa en profundidad se realiza mediante una cuidadosa separación de responsabilidades, de modo que comprometer el sistema requiera algo más que comprometer un elemento o un actor. Los mineros por sí solos no pueden robar los fondos de la clavija, ni los funcionarios, ni el fabricante de PowHSM, ni los desarrolladores. El proceso de la clavija se rige por reglas de consenso aplicadas en software y firmware, cada uno de los cuales protege al otro de fallos y vulnerabilidades. Además, la comunidad Rootstock protege el código de los errores. El objetivo de la comunidad es mejorar el Powpeg añadiendo más capas protectoras, cada capa añadiendo más seguridad. + +Como se ha descrito anteriormente, cada funcionario no sólo gestiona un nodo Powpeg, sino también un PowHSM. En los próximos meses, todos los miembros actuales del Powpeg habrán terminado de actualizarse a la versión 2.0 del PowHSM. Como ya se ha explicado, cada PowHSM ejecuta un nodo de consenso en modo SPV, por lo que los comandos deben estar respaldados por hashrate real. Engañar al PowHSM se hace muy difícil, si no imposible, sin piratear varios pools de minería de Bitcoin. + +El término "vetocracia" es muy útil en este contexto. Una vetocracia es un sistema de gobierno en el que ninguna entidad puede adquirir por sí sola el poder suficiente para tomar decisiones y hacerse cargo de forma efectiva. El enfoque de defensa en profundidad de Rootstock para la seguridad del Powpeg sigue una ideología de este tipo, que hace que los ataques sean ineficaces. Una buena pregunta a la hora de diseñar un sistema peg bidireccional debería ser: "¿en qué medida se parece el protocolo a una vetocracia?", ahorrando a muchos interminables debates religiosos sobre sistemas federados frente a descentralizados. + +## Coordinación Transparencia + +Todas las comunicaciones entre funcionarios se producen a través de la blockchain de Rootstock. No hay mensajes ocultos entre funcionarios y no existe ningún subsistema preestablecido que les permita comunicarse en secreto. Todos los mensajes intercambiados son públicos. Aunque no podemos impedir la comunicación oculta por parte de hipotéticos atacantes con pleno control del código ejecutable del nodo Powpeg, sí evitamos la colusión oculta durante largos periodos. Como la coordinación se lleva a cabo a través de la red pública, el sistema obliga a las PowHSM a estar expuestas a la mejor cadena honesta de blockchain, y permite que todos los participantes de la red conozcan periódicamente el estado interno de las PowHSM. En cuanto a los hackers externos, la existencia de un sistema preestablecido de coordinación oculta sería una poderosa herramienta para la escalada de privilegios, ya que puede utilizarse para obtener las IP de los funcionarios e intentar ataques selectivos. Los funcionarios de Powpeg podrían conectarse a la red a través de Tor, o cambiar sus IP diariamente sin problema. + +Por último, el contrato inteligente puente construye la transacción peg-out y no deja que ninguno de los PowHSM elija nada relacionado con la transacción para firmar. Todo el contenido de la transacción se decide por consenso en Rootstock. + +## Certificación de firmware + +Los firmwares de Rootstock PowHSM, así como el nodo completo y los nodos Powpeg, se generan utilizando compilaciones deterministas, aunque actualmente la instalación del firmware en los PowHSM no puede ser totalmente libre de confianza. Un grupo de auditoría debe dar fe de la corrección del proceso de instalación del firmware en cada nuevo dispositivo o lote de dispositivos. Pero estamos mejorando esta área con una nueva defensa: la próxima iteración del firmware PowHSM (versión 2.1) es capaz de proporcionar atestación de firmware utilizando características de seguridad proporcionadas por el dispositivo. Por lo tanto, el próximo objetivo es incluir la atestación del firmware como parte de los procedimientos de despliegue de Rootstock, o incluso periódicamente como mensajes _keepalive_. Pronto, los mensajes de atestación se almacenarán en la cadena de bloques y todos los miembros de la comunidad podrán validar los firmwares PowHSM. + +## La prueba del trabajo es la prueba del tiempo + +El trabajo acumulativo requerido por el PowHSM también funciona como un limitador de tasa o **retraso de tiempo forzado** para cualquier ataque: Dado el hecho de que Rootstock tiene una gran parte del hashrate de Bitcoin a través de la minería merge, la cantidad de dificultad acumulada necesaria para "engañar" al PowHSM para que confirme un peg-out sobre una rama bifurcada maliciosa implica una colusión a gran escala por parte de algunos de los principales pools de minería de Bitcoin durante varios días. Un ataque de este tipo sería transparente y visible para las comunidades Bitcoin y Rootstock. Al igual que en los [procedimientos de apertura] de las cámaras acorazadas bancarias (https://www.law.cornell.edu/cfr/text/12/208.61), el PowHSM está aplicando en realidad un [tiempo de retardo] (https://en.wikipedia.org/wiki/Time_lock) que permite a los humanos entrar en el bucle si se sospecha de un ataque. + +## Peg-in y Peg-out Finalidad + +Dado que la blockchain de Bitcoin y la sidechain de Rootstock no están entrelazadas en una única blockchain o en una relación padre-hijo como en una [syncchain](https://blog.rootstock.io/noticia/syncchain-synchronized-sidechains-for-improved-security-and-usability/), las transferencias de bitcoins entre ellas deben considerarse definitivas en algún momento. De lo contrario, los bitcoins bloqueados en un lado nunca podrían desbloquearse con seguridad en el otro. **Por lo tanto, las transacciones "peg-in" y "peg-out" requieren un gran número de confirmaciones de bloque. Las peg-ins requieren 100 bloques Bitcoin (aproximadamente 2000 bloques RSK), y las peg-outs requieren 4000 bloques Rootstock (aproximadamente 200 bloques Bitcoin)**. Las transacciones firmadas por los nodos de la federación son consideradas definitivas por Rootstock: estas transacciones se difunden y se asume que se incluirán tarde o temprano en el blockchain de Bitcoin. Debido a la necesidad de finalidad, el consenso de Rootstock no intenta recuperarse de un ataque que consiga revertir la blockchain lo suficientemente profundo como para revertir una transacción final peg-in o peg-out. Si se produce una gran reversión, los nodos Powpeg detienen cualquier peg-out futuro, y los actores maliciosos no deberían ser capaces de duplicar el peg. + +:::note[IRIS 3.0.0] +Desde la actualización de IRIS 3.0.0, los valores mínimos requeridos para peg-in y peg-out se han reducido a la mitad, Peg-in (BTC) mínimo es ahora 0,005 y Peg-out (RBTC) mínimo es ahora 0,004. Además de este mínimo, el Bridge estimará las tasas necesarias para pagar el pegout, si el remanente después de pagar las tasas es demasiado bajo (no es suficiente para ser gastado en BTC) el pegout será rechazado. Los fondos serán reembolsados si el pegout es rechazado por cualquiera de las condiciones descritas anteriormente. +::: + +## Descentralización - Construir una vetocracia + +El uso de PowHSMs en una federación es un paso adelante en la descentralización, porque un funcionario comprometido remotamente no compromete el elemento principal para la seguridad de la clavija: una clave privada multisig. Dado que Rootstock tiene una gran parte del hashrate minado por fusión de Bitcoin, que actualmente supera el 51%, parece extremadamente improbable que un nuevo grupo de mineros por fusión pueda secuestrar el consenso el tiempo suficiente para forzar a los PowHSM a realizar un peg-out malicioso. Pero la comunidad Rootstock no debería dormirse en los laureles. En su lugar, la comunidad Rootstock planea aplicar una vez más un enfoque por capas que conduzca a una mayor "seguridad aditiva". + +## La resistencia a la censura de Powpeg + +El Powpeg de Rootstock también es único por el limitado conjunto de responsabilidades delegadas a cada nodo del Powpeg. En particular, los funcionarios del Powpeg no pueden aplicar una censura selectiva a las transacciones de entrada y salida. Si un funcionario del Powpeg intenta censurar una operación concreta, los demás funcionarios firman y ejecutan la operación de "peg-out", con lo que la censura fracasa. Si todos los funcionarios intentan censurar una transacción, los funcionarios no pueden seguir realizando otras operaciones de "peg-out", ya que las operaciones de "peg-out" están vinculadas a UTXOs, y los funcionarios no pueden elegir los UTXOs para las transacciones de "peg-out". Los UTXOs de peg-out, incluidos los UTXOs de "cambio", son seleccionados por el contrato Bridge, formando una cadena reforzada por consenso. Por lo tanto, prohibir selectivamente una transacción conduce finalmente a la paralización completa del Powpeg, y por eso la censura selectiva no es posible. + +En cuanto al cierre completo del Powpeg por un solo gobierno, sería muy difícil de llevar a cabo, ya que los funcionarios están distribuidos geográficamente por todo el mundo. Para protegerse de poderosos ataques coordinados en todo el mundo o de ataques procedentes de agencias de tres letras, Rootstock planea añadir un bloqueo temporal multisig de recuperación de emergencia que se activará un año después de que se demuestre el desmantelamiento del Powpeg. Un intento de cierre sólo haría a Rootstock más fuerte y resistente a ataques posteriores, ya que un nuevo Powpeg de Rootstock se expandiría rápidamente y se descentralizaría en un centenar de usuarios individuales de todo el mundo, cada uno ejecutando un dispositivo PowHSM y un nodo Powpeg sobre Tor. + +## Conclusión + +La paridad Rootstock ha pasado de ser una federación a ser un Powpeg. A medida que la clavija crece con el tiempo, más bitcoins se trasladan a Rootstock. Los desarrolladores pueden encontrar una oportunidad única para construir sus dApps en nuestra bóveda monetaria segura y eficiente. En comparación con otras alternativas, el Powpeg combina una fuerte seguridad basada en protecciones por capas, con la máxima descentralización dentro de las limitaciones establecidas por el sistema de scripting de Bitcoin. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/powpeg/security-model.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/powpeg/security-model.md new file mode 100644 index 00000000..e27da2a1 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/powpeg/security-model.md @@ -0,0 +1,31 @@ +--- +title: Modelo de seguridad +sidebar_position: 200 +sidebar_label: Modelo de seguridad +tags: + - Portainjerto + - seguridad + - powpeg + - arquitectura + - federación + - Clavija de 2 vías +description: Lograr la seguridad en una cadena lateral Powpegged utilizando pruebas de pago +--- + +Una cadena lateral es una cadena de bloques independiente cuya moneda nativa está vinculada al valor de otra moneda de la cadena de bloques. La vinculación puede ser impuesta por un protocolo o puede ser sintética. Un [2-way peg](/conceptos/powpeg/) es un sistema reforzado por protocolo que permite que dos monedas se intercambien libremente, de forma automática, y sin incurrir en una negociación de precios. En Rootstock, el activo que se puede mover libremente es Bitcoin. Cuando la red donde existen los bitcoins no está clara por el contexto, nos referimos a RBTC a los bitcoins existentes en Rootstock. + +En la práctica, cuando se intercambia BTC por RBTC, no se "transfiere" ninguna moneda entre blockchains en una única transacción. La operación de transferencia se divide en dos transacciones. En la primera, algunos BTC se bloquean en Bitcoin y en la segunda se desbloquea la misma cantidad de RBTC en Rootstock. Todo el proceso se denomina peg-in. Cuando el RBTC necesita volver a convertirse en BTC, se produce el proceso inverso: el RBTC se bloquea de nuevo en Rootstock y la misma cantidad de BTC se desbloquea en Bitcoin. El proceso se denomina peg-out. + +Si dos plataformas tienen smart-contracts Turing-completos, se pueden crear pegs bidireccionales totalmente minimizados y libres de terceros. Pero dado que Bitcoin no soporta actualmente contratos inteligentes completos de Turing ni opcodes nativos para validar pruebas SPV externas, parte del sistema de 2 vías de Rootstock se basa en un sistema autónomo llamado Powpeg. Este sistema consta de un contrato inteligente llamado Bridge, que controla todas las operaciones, y un conjunto de terceros llamados pegnatories, cada uno de los cuales ejecuta un software llamado nodo Powpeg y un módulo de seguridad de hardware llamado PowHSM. El PowHSM es un dispositivo a prueba de manipulaciones encargado de almacenar una clave privada que forma parte de un esquema multifirma. En el proceso de peg-in, los usuarios envían bitcoins a esta dirección multifirma. Los PowHSM también son responsables de elegir la mejor cadena de Rootstock basándose en la prueba de trabajo acumulativa, en un modelo de seguridad llamado SPV, y de firmar las transacciones de peg-in de Bitcoin en caso de que el consenso de la blockchain de Rootstock lo requiera. **Ningún pegnatario puede controlar los BTC bloqueados, ni acceder a la clave privada multi-sig almacenada en el PowHSM. Ni siquiera la mayoría de los pegnatorios tiene capacidad para liberar fondos de BTC**. El PowHSM sólo procede a firmar una transacción de peg-out al recibir órdenes de la blockchain de Rootstock, respaldadas por 4000 bloques de confirmación, con una prueba de trabajo acumulativa equivalente actualmente a aproximadamente 100 bloques de bitcoin. Tenga en cuenta que si un usuario transfiere BTC a RBTC y viceversa, normalmente no recibirá bitcoins que estén directamente conectados por UTXOs con el BTC original enviado. Los bitcoins no están bloqueados para usuarios específicos, sino que están bloqueados para su uso en toda la red Rootstock. + +El bloqueo y desbloqueo de fondos lo realiza el Powpeg sin intervención humana. Un requisito para formar parte del Powpeg es la capacidad de mantener el dispositivo PowHSM en línea y conectado a la red Rootstock con un alto tiempo de actividad. También es un requisito que los pegnatorios sean capaces de auditar o revisar auditorías de terceros que atestigüen que el software que alimenta el nodo se comporta como se espera. El dispositivo PowHSM está fabricado por una empresa puntera en seguridad de hardware y el firmware ha sido desarrollado por RootstockLabs. El PowHSM proporciona la máxima seguridad de vanguardia para sus claves privadas utilizando un Elemento Seguro (SE). + +A partir de enero de 2020, el Powpeg comprende 12 pegnatorios conocidos y altamente seguros. Las principales empresas de Blockchain son actualmente miembros del Powpeg. A cambio de su trabajo, los pegnatorios reciben el 1% de las comisiones por transacción generadas en Rootstock, con el fin de cubrir los costes de hardware y mantenimiento. + +## Novedades para los miembros de Powpeg + +El Powpeg se rige por un protocolo escrito que establece cuándo es posible o necesario añadir o eliminar un miembro. Si se cumplen las condiciones para cambiar la composición, un pegnatario puede enviar un mensaje al contrato Puente exigiendo el inicio de un cambio de composición del Powpeg. El cambio implica tres fases: un periodo de votación, un periodo de retraso y un periodo de migración de fondos. Todas las fases están automatizadas y coordinadas por el contrato Puente, por lo que el proceso es abierto, público y deja una pista de auditoría criptográfica. Durante la fase de votación, cada pegnatario puede aceptar o rechazar un cambio de composición. Sólo si la mayoría de los pegnatorios acepta el cambio, comienza la siguiente fase. Esta fase consiste en un retraso de una semana impuesto por consenso. El retraso permite a los usuarios transferir los Bitcoins de vuelta a la red Bitcoin en caso de que no confíen en la nueva composición Powpeg. Por último, se activa el cambio de composición y comienza la última fase, que se encarga de la migración de los fondos del antiguo Powpeg al nuevo. + +## El futuro + +Una de las características que ha sido aceptada por la comunidad es la adición de la atestación pública del firmware de las PowHSM para que todos los usuarios puedan verificar la corrección de las mismas. Otra característica futura es la introducción de keep-alives frecuentes para detectar lo antes posible si un pegnatorio está caído. Existen varias propuestas de la comunidad que compiten entre sí sobre cómo mejorar la seguridad del Powpeg. Si Bitcoin añade opcodes especiales o extensibilidad para validar las pruebas SPV, y una vez que se demuestre que el nuevo sistema es seguro y libre de confianza, el papel del Powpeg ya no será necesario, y la comunidad Rootstock puede implementar los cambios para adaptar Rootstock al nuevo sistema libre de confianza. Por ejemplo, los miembros de la comunidad Rootstock propusieron en 2016 un BIP drivechain, que representa una alternativa al Powpeg minimizada por la confianza. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion-with-ledger.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion-with-ledger.md new file mode 100644 index 00000000..1a9c9d65 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion-with-ledger.md @@ -0,0 +1,225 @@ +--- +title: Conversión utilizando un monedero físico Ledger +sidebar_label: Libro mayor +tags: + - rsk + - portainjertos + - rbtc + - conversión + - peg + - clavija + - peg-out + - federación + - Libro mayor +description: Cómo realizar el mecanismo Powpeg utilizando Ledger. +sidebar_position: 304 +--- + +En esta sección, repasaremos los pasos para convertir BTC a RBTC utilizando el monedero hardware de Ledger, y viceversa en las redes Bitcoin y Rootstock (RSK). + +## Requisitos generales + +- Necesita un [Ledger](https://www.ledger.com/) con Bitcoin y + Rootstock Apps instalados. Le recomendamos que tenga + [Ledger Live](https://www.ledger.com/ledger-live) + y revise este tutorial: +- Necesitas tener [Electrum](https://electrum.org/). + Instálalo y [configúralo para utilizarlo con Ledger](https://support.ledgerwallet.com/hc/en-us/articles/115005161925-Set-up-and-use-Electrum). +- Nodo >= 10.16.0 + +## Conversor de BTC a RBTC + +Instrucciones sobre cómo hacer un peg-in en Mainnet. + +### Obtener una dirección BTC con saldo + +Recomendamos utilizar el monedero Electrum BTC para conectarse a +BTC Mainnet utilizando el monedero de hardware Ledger. + +- Descargue el monedero de + [Sitio web de Electrum](https://bitzuma.com/posts/a-beginners-guide-to-the-electrum-bitcoin-wallet/) +- Instalar Electrum +- Conecta y desbloquea tu dispositivo Ledger. +- Abrir la aplicación Bitcoin +- Inicio Electrum +- Una vez iniciado Electrum, crea o importa un monedero +- En la pantalla del almacén de claves, seleccione Utilizar un dispositivo de hardware y haga clic en Siguiente. +- Seleccione su dispositivo Ledger y haga clic en Siguiente. +- Elija la ruta de derivación adecuada para su cuenta y haga clic en Siguiente: + - Legado para una cuenta que tiene direcciones que empiezan por 1 +- Vaya a la tercera pestaña "Recibir". Verás una dirección Bitcoin. + +:::info[Note] +El monedero Bitcoin debe ser heredado (no Segwit) +cuya clave pública empiece por `m` o `n`, +y la clave privada empiece por `p2pkh:`. +::: + +### Encontrar una dirección BTC con saldo + +Tendrá que encontrar la dirección BTC correspondiente derivada +de la ruta de derivación BTC en la pestaña "Recibir" de Electrum. + +- Compruebe la ruta de derivación para BTC que se va a utilizar: + - Mainnet: `44'/0'/0'/0/0` + [BIP 44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) **Legacy** +- Desbloquea Ledger y abre la **App Bitcoin**. +- Para obtener la dirección BTC derivada de la ruta de derivación que ha especificado. Ejecute el siguiente script: + ```js + const Transport = require("@ledgerhq/hw-transport-node-hid").default; + const AppBtc = require("@ledgerhq/hw-app-btc").default; + + const getBtcAddress = async (derivationPath = "44'/0'/0'/0/0") => { + try{ + const transport = await Transport.create(); + const btc = new AppBtc(transport); + const result = await btc.getWalletPublicKey(derivationPath); + + console.log('BTC Address'); + console.log(result.bitcoinAddress); + console.log('Derivation Path: ' + derivationPath); + } + catch(err){ + console.log(err); + } + }; + + (async () => { + await getBtcAddress("44'/0'/0'/0/0"); + })(); + ``` +- Después de eso usted debe obtener un resultado similar a: + ```text + Dirección BTC + 12dAR91ji1xqimzdTQYHDtY....ppSR + Ruta de derivación: 44'/0'/0'/0/0 + ``` + +:::tip[Tip] +Esta es la dirección que tienes que utilizar para hacer la transferencia a la federación. +::: + +### Enviar Bitcoin a la dirección de Rootstock Federation + +:::warning[Warning] +Usted necesita enviar una cantidad mínima de 0,01 BTC o cantidad máxima, +no más de 10 BTC para la conversión. +::: + +Para obtener la dirección de Rootstock Federation puede ejecutar el siguiente script: + +```javascript +const Web3 = require('web3'); +const precompiled = require('@rsksmart/rsk-precompiled-abis'); + +const getFederationAddress = async function(){ + const bridge = precompiled.bridge.build(new Web3('https://public-node.rsk.co')); + const address = await bridge.methods.getFederationAddress().call(); + console.log('Dirección de la Federación:'); + console.log(address); +} + +(async () => { + await getFederationAddress(); +})(); +``` + +Una vez que tenga la dirección de la Federación Rootstock, puede enviarle Bitcoin desde su dirección Bitcoin. + +Utiliza Electrum para enviar BTCs a la dirección de la federación Rootstock. Para ello: + +- Abrir Electrum +- Ir a la pestaña Direcciones +- Haga clic con el botón derecho del ratón +- Seleccione la opción "Gastar desde": + ![Gastar desde](/img/concepts/peg-ledger/electrumSpendFromOption.png) +- Por último, realice un pago a la dirección de la Federación RSK + ![Sending Payment](/img/concepts/peg-ledger/electrumSpendFrom.png) + +**4 Esperar confirmaciones de BTC** + +Para garantizar la transacción, tenemos que esperar 100 confirmaciones BTC, sea paciente : + +:::tip[Tip] +100 bloques \* 10 minutos/bloque = 1000 minutos = 16,667 horas aprox. +::: + +**5 Obtener la dirección RBTC del monedero Ledger harware** + +Obtenga la dirección RBTC correspondiente de su monedero Ledger harware, siguiendo estos pasos: + +- Conecta y desbloquea tu dispositivo Ledger. +- Abra la aplicación RSK. +- Obtener la dirección derivada de RSK ejecutando este script: + ```javascript + const Transport = require("@ledgerhq/hw-transport-node-hid").default; + const AppEth = require("@ledgerhq/hw-app-eth").default; + + const getRskAddress = async (derivationPath = "44'/0'/0'/0/0") => { + try{ + const transport = await Transport.create(); + const eth = new AppEth(transport); + const result = await eth.getAddress(derivationPath); + + console.log('RSK Address'); + console.log(result.address); + console.log('Derivation Path: ' + derivationPath); + } + catch(err){ + console.log(err); + } + }; + + (async () => { + await getRskAddress("44'/0'/0'/0/0"); + })(); + + ``` +- Vaya a MyCrypto y conéctese a la cartera Ledger harware. +- Seleccione **Dirección personalizada** y ponga la ruta de derivación `m/44'/0'/0'/0`. + A continuación, elija la dirección que obtuvo en el paso anterior. + +**6 Comprobar saldo RBTC** + +Puede comprobar el saldo de la dirección RBTC en MyCrypto o MEW configurando la ruta de derivación correspondiente y seleccionando la dirección. + +:::info[Note] +Tiene que esperar un mínimo de 100 confirmaciones + un mínimo de 5 minutos para consultar su saldo de RBTC +::: + +## Conversion RBTC a BTC + +Instrucciones sobre cómo hacer un peg-out de Mainnet. + +1. Obtener dirección BTC con Ledger hardware wallet + +Si has olvidado tu dirección pública de BTC, puedes consultar el apartado **1**. +Lo importante es que el receptor es BTC dirección será +la misma que se utilizó para enviar a la federación. + +2. Enviar RBTC a Rootstock Bridge Contract + +Abra MyCrypto o MEW. +Establezca la ruta de derivación correspondiente y seleccione la dirección. \ +Esta dirección tiene que ser la misma que la de la sección **6**. +A continuación, realice una transacción al contrato puente. + +> Dirección del contrato puente: `0x0000000000000000000000000000000001000006` + +:::info\[Note] + +- La cantidad mínima a enviar en una transacción de "peg-out" debe ser mayor o igual a 0,004 **RBTC** para Mainnet y la cantidad mínima a enviar en una transacción de "peg-in" debe ser mayor o igual a 0,005 **BTC** para Mainnet. +- El límite de gas de la transacción debe fijarse manualmente en 100.000 gas; de lo contrario, la transacción fallará. +- El precio del gas puede fijarse en 0,06 gwei. + ::: + +![Personalizar Gas en Metamask antes de enviar transacción en Rootstock](/img/concepts/metamask-gas-limit.png) + +3. Comprobar el saldo de la dirección BTC + +Puede utilizar el monedero Electrum descargado anteriormente o +cualquier explorador de Bitcoin para comprobar el saldo. + +:::info[Note] +El proceso de liberación en la red Bitcoin lleva 4000 confirmaciones de bloque RSK y al menos 10 minutos más. +::: diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion-with-node-console.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion-with-node-console.md new file mode 100644 index 00000000..9fd84973 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion-with-node-console.md @@ -0,0 +1,81 @@ +--- +title: Conversión con nodo y consola +sidebar_label: Nodo y consola +tags: + - rsk + - rbtc + - conversión + - peg + - 2 vías + - clavija + - peg-out + - federación + - nodo + - cli +description: Cómo realizar el mecanismo Powpeg mediante nodo y consola. +sidebar_position: 305 +--- + +En esta sección se explica cómo probar el mecanismo Powpeg utilizando +su nodo Rootstock y una línea de comandos. + +## Requisitos generales + +- Necesitas tener el control total de tu clave privada de BTC. +- Necesitas una Cartera BTC correctamente configurada utilizando dicha clave privada. +- Necesita un nodo Rootstock en funcionamiento, + con la interfaz RPC activada y los módulos personal y eth activados. + - Véase [¿cómo se ejecuta un nodo Rootstock?](/node-operators/setup/). + +## Conversor de BTC a RBTC + +Cómo realizar un clavado. + +:::warning\[Warning] + +Lea los [requisitos de bloqueo](/concepts/rbtc/networks#mainnet-conversion) + +::: + +1. Con su dirección Bitcoin, + envía una transacción BTC a la dirección de la federación Rootstock. +2. Utilizando su explorador de bloques de BTC preferido + (por ejemplo, [Blocktrail](https://www.blocktrail.com/BTC)), + siga su transacción y espere el tiempo estipulado. +3. Convierte la clave privada al formato Rootstock con esta herramienta: + [https://github.com/rsksmart/utils](https://github.com/rsksmart/utils)), + y escriba la información de su cuenta Rootstock. +4. A continuación, utilice el [Rootstock Testnet Explorer](https://explorer.testnet.rootstock.io) + o el [Rootstock Mainnet Explorer](https://explorer.rootstock.io) + para ver su saldo de RBTC. + Recuerde que las direcciones de Rootstock deben empezar por `0x`. + +## Conversion RBTC a BTC + +Cómo realizar un peg-out. + +:::warning\[Warning] + +Lea los [requisitos de publicación](/concepts/rbtc/networks#rbtc-to-btc-conversion) + +::: + +1. Añada su clave privada Rootstock obtenida a su nodo Rootstock. + Sustituya `RSKConvertedPrivateKey`, `RSKNode` y `RSKNodePort` + y ejecute este comando: + ```shell + $ curl -X POST --data '{"method": "personal_importRawKey", "params":["", ""], "jsonrpc": "2.0", "id":1}' http://: + ``` +2. Desbloquea tu cuenta para transferencias. + Sustituye `RSKAddress`, `passPhraseJustUsedToEncryptPrivKey`, `RSKNode` + y `RSKNodePort` y ejecuta: + ```shell + $ curl -X POST --data '{"method": "personal_unlockAccount", "params":["", "", ""], "jsonrpc": "2.0", "id":1}' http://: + ``` +3. Transfiera la cantidad que desee. + Sustituya `RSKAddress`, `valueToReleaseInWeis`, `RSKNode` y `RSKNodePort` + y ejecute: + ```shell + $ curl -X POST --data '{"method": "eth_sendTransaction", "params":[{"from": "", "to": "0x0000000000000000000000000000000001000006", "gasPrice": 59240000, "gas": 44000, "value": }], "jsonrpc": "2.0", "id":1}' http://: + ``` +4. Espera el tiempo estipulado y comprueba tu saldo de BTC. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion-with-trezor.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion-with-trezor.md new file mode 100644 index 00000000..e9a77981 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion-with-trezor.md @@ -0,0 +1,52 @@ +--- +title: Acceso y uso de fondos que no están en cuentas derivadas con Rootstock (RSK) dpath en Trezor T +sidebar_label: Con Trezor T +tags: + - rsk + - rbtc + - conversión + - peg + - 2 vías + - clavija + - peg-out + - federación + - trezor + - dpath +description: Cómo configurar un monedero hardware Trezor T para derivar con un dpath personalizado. +sidebar_position: 306 +--- + +Cómo resolver el problema de mover sus fondos cuando están en una cuenta que necesita +ser derivada con una ruta de derivación personalizada (dpath) utilizando Trezor T. + +## Contexto + +Si has hecho una [conversión de BTC a RBTC](/concepts/rbtc/conversion-with-ledger#btc-to-rbtc-conversion) usando Trezor T, necesitas acceder a tu cuenta usando un dpath personalizado (`44'/0'/0'/0/0` para Mainnet). Con las últimas versiones de firmware, Trezor T está comprobando que la dpath coincide con la esperada como una característica de seguridad y esto es un bloqueador cuando se tiene la intención de utilizar una dpath diferente. +También es posible que desee acceder a su cuenta con un dpath diferente si ha cometido un error; por ejemplo, recibir RBTC en una dirección derivada utilizando el dpath de Ethereum en lugar del dpath de Rootstock. + +En MyCrypto o MyEtherWallet puede haber recibido este mensaje: `"Ruta de clave prohibida"`. + +## Solución + +Para permitir rutas de derivación personalizadas, deberá desactivar las comprobaciones de seguridad (véase [mensaje de Pavol Rusnak](https://github.com/trezor/trezor-firmware/issues/1255#issuecomment-691463540)). + +Para ello, debe instalar [python-trezor](https://github.com/trezor/python-trezor): + +```shell +pip3 install --upgrade setuptools +pip3 install trezor +``` + +Una vez que esté listo, ejecute este comando: + +```shell +trezorctl set safety-checks prompt +``` + +(necesitas tener tu Trezor T desbloqueado y aceptar la configuración en el dispositivo) + +Después de mover tus fondos, puedes volver a activarlos: + +```shell +trezorctl set safety-checks strict +``` diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion.md new file mode 100644 index 00000000..8d71a2a4 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/conversion.md @@ -0,0 +1,86 @@ +--- +title: "Conversión RBTC: Peg in y Peg out" +sidebar_label: Entrada y salida de clavijas +tags: + - rsk + - portainjertos + - rbtc + - conversión + - peg + - 2 vías + - clavija + - peg-out + - federación + - powpeg +description: Conversión de RBTC a BTC (peg-in) y de BTC a RBTC (peg-out), tanto para Mainnet como para Testnet. +sidebar_position: 301 +--- + +En este artículo, explicamos paso a paso cómo convertir de BTC a RBTC, y viceversa. +El proceso de conversión utiliza un mecanismo [Powpeg](/concepts/powpeg/). Por lo tanto, estas conversiones se denominan peg-ins y peg-outs. + +- **Peg-in**: + - Conversión de BTC a RBTC + - Bloquea BTC en la dirección de la Federación BTC + - Libera RBTC en la dirección derivada de Rootstock +- **Peg-out**: + - Conversión de RBTC a BTC + - Bloquea RBTC en la red Rootstock + - Libera BTC en la red Bitcoin + +## Compatibilidad + +**Los tipos de direcciones que se aceptan para la Federación son**: + +- Legado (P2PKH) +- Compatible con Segwit (P2SH-P2WPKH) + +:::info[Note] +En las Testnets, los símbolos de los tokens van precedidos de una "t" minúscula. +Así, tenemos `BTC` y `RBTC` en las Mainnets, que corresponden a `tBTC` y `tRBTC` de las Testnets. +::: + +### Verificador de direcciones + +Introduzca a continuación su dirección de BTC para comprobar si puede utilizarse para pasar de BTC a RBTC. + +## Guía del usuario + +- [Guía Mainnet](/concepts/rbtc/networks#mainnet-conversion) +- [Guía Testnet](/concepts/rbtc/networks#testnet-conversion) + +Puede probar el proceso de conversión utilizando cualquiera de las opciones siguientes; + +- Utilizar una [cartera hardware ledger](/concepts/rbtc/conversion-with-ledger) +- Utilizando un [software](/conceptos/rbtc/conversion-con-nodo-consola) + +## Vídeo + +Vea este vídeo explicativo sobre **Cómo realizar conversiones BTC y R-BTC utilizando el Powpeg de Rootstock**. + +
+ +
+ +### Preguntas frecuentes + +```mdx-code-block + + + ¿Con qué frecuencia cambia la dirección de la Federación de Rootstock? + + La dirección de la Federación de Rootstock ha cambiado varias veces desde el lanzamiento de la red principal de Rootstock. + + + + ¿Pierdo mi Bitcoin si la dirección de la Federación Rootstock cambia durante mi transferencia? + + Hay un periodo de gracia para el cambio de dirección de la Federación de Rootstock. Aún podrá bloquear Bitcoin y obtener RBTC durante el periodo de gracia. Sin embargo, cualquier Bitcoin enviado a la antigua dirección de la Rootstock Federation se perderá después del periodo de gracia. + + + +``` + +### Comentarios + +Únase a la [Rootstock Global Discord Community](https://rootstock.io/discord), para hacer preguntas y obtener respuestas. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/gas.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/gas.md new file mode 100644 index 00000000..aebd657b --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/gas.md @@ -0,0 +1,149 @@ +--- +title: "Tarifas de gas RBTC: Optimización de los costes de transacción" +sidebar_label: Gas +tags: + - gas + - transacciones + - rbtc + - red principal + - rsk + - portainjertos + - conversión + - bitcoin + - precio del gas +sidebar_position: 302 +--- + +El gas es el precio interno por ejecutar una transacción o contrato. +Cuando envías tokens, interactúas con un contrato, envías RBTC o haces cualquier otra cosa en la blockchain, debes **pagar por ese cálculo**. Ese pago se calcula como **gas**. En Rootstock, se paga en RBTC. + +## ¿Qué es el gas? + +Hay cuatro conceptos importantes: + +- \*\*El precio del gas: El coste de la operación. +- **Límite de gas**: El gas máximo que puede permitirse la operación. Es un límite superior que el usuario establece para evitar perder gas. +- **Gas total**: El gas que ha consumido la operación. También se denomina **gas utilizado**. +- \*\*Unidad: El gas se paga en **RBTC**. + +Empecemos con una analogía sencilla: Un coche. + +Para conducir un coche necesitas gasolina. El precio de la gasolina es el dinero que pagas por cada galón. El límite de gasolina es la cantidad máxima de gasolina que aceptas consumir, la gasolina que _cargas_. El total de gasolina es la cantidad que has gastado al final del viaje. +Puedes calcular el gas total y establecer un límite de gas adecuado para que tu viaje no gaste más de lo previsto. + +Las transacciones son bastante similares: + +El precio del gas es el precio que usted fija para las operaciones. El límite de gas es el precio máximo que va a pagar por la transacción cuando se opere. Entonces, cuando se ejecuta la transacción, el gas total es el precio que finalmente pagas. + +El gas es la _fee_ cobrada por el minero que mina el bloque que incluye la transacción. + +La tasa resultante es: + +``` +tarifa = totalGas * precioGas +``` + +## ¿Cómo elijo un precio y un límite de gasolina adecuados? + +Si quiere gastar menos en una transacción, puede hacerlo reduciendo la cantidad que paga por unidad de gas (precio del gas). Al igual que en Bitcoin, el precio que pagas por cada unidad aumenta o disminuye la **rapidez con la que se minará tu transacción.** + +### Precio adecuado del gas + +El precio del gas cambia con el tiempo. Para elegir un precio del gas adecuado debes tener en cuenta 2 conceptos: + +- Qué es el _precio mínimo del gas_ y cómo cambia +- Cómo conseguir ese _precio mínimo de la gasolina_ + +### Precio mínimo del gas + +El `minimumGasPrice` lo escriben los mineros en la cabecera del bloque y establece el precio mínimo del gas que debe tener una transacción para ser incluida en ese bloque. Puede cambiar con el tiempo, hasta un 1% del `minimumGasPrice` del bloque anterior. El precio mínimo del gas del último bloque puede obtenerse utilizando este método Web3: + +Los medios por los que los mineros negocian el precio mínimo del gas se describen en [RSKIP09](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP09.md). + +```javascript +web3.eth.getBlock('latest').precioMinimoGas +``` + +:::tip[Gas Límite] + +El límite de gas de transacción por bloque es de 6.800.000 unidades. + +::: + +He aquí algunos enfoques prácticos de este tema: + +1. Enfoque optimista (no recomendado): + Puede establecer `minimumGasPrice` como parámetro del precio del gas para la transacción **pero si el precio mínimo del gas está siendo negociado y sube, su transacción podría ser rechazada**. + +2. Enfoque sensato: + En lugar de utilizar "precio mínimo del gas" tal y como está, puede [añadir un 10% a su valor](#cómo-cambia-el-precio-del-gas-con-el-tiempo). + +3. Enfoque de la media de la red: + Puedes obtener el precio medio del gas que se está pagando en la red: + +```javascript +web3.eth.preciogas() +``` + +Aunque este valor sea mayor o igual que el precio mínimo del gas. (`gasPrice >= minimumGasPrice`), se recomienda añadir un pequeño porcentaje para aumentar la prioridad de su transacción. + +### Límite de gas adecuado + +El gas total puede estimarse utilizando este método Web3: + +```javascript +myContract.methods.myMethod(param1, param2, ...).estimateGas(options, callback) +``` + +> Visite [aquí](https://web3js.readthedocs.io/en/1.0/web3-eth-contract.html#methods-mymethod-estimategas) para consultar la documentación de Web3. + +### Más información + +#### ¿Cómo varía el precio del gas con el tiempo? + +Cada minero puede votar para aumentar o disminuir el "precio mínimo del gas" hasta un 1%. Esto permite a los mineros aumentar el "precio mínimo del gas" un 100% en aproximadamente 50 minutos, suponiendo un bloque cada 30 segundos. +Los nodos que reenvían transacciones podrían comprobar que el **precio del gas anunciado en una transacción es al menos un 10% superior al mínimo**. Esto asegura a la transacción una vida útil de 10 bloques, suponiendo un "precio mínimo del gas" en bloque en constante aumento. +El precio mínimo del gas negociado se describe en [RSKIP09](https://github.com/rsksmart/RSKIPs/blob/master/IPs/RSKIP09.md). + +## ¿Qué ocurre si falla mi transacción? + +\*\*Incluso si falla, los mineros deben validar y ejecutar su transacción (solicitud de cálculo) y, por tanto, usted debe pagar por ese cálculo igual que pagaría por una transacción exitosa. + +## ¿Qué pasa si me quedo sin gasolina? + +Si una transacción alcanza el límite de gas, se revertirán todos los cambios pero **se seguirá pagando la tasa**. + +## El gas en los contratos inteligentes + +Cuando compilas contratos inteligentes (comúnmente escritos en [Solidity](https://solidity.readthedocs.io/en/latest/)), se convierten en códigos de operación, conocidos como `opcodes`. +Estos códigos (opcodes) se muestran con nombres mnemotécnicos como `ADD` (suma) o `MUL` (multiplicación). [Aquí](https://github.com/rsksmart/rskj/blob/master/rskj-core/src/main/java/org/ethereum/vm/GasCost.java) puedes ver el precio de cada opcode. +Como puedes adivinar, es importante escribir contratos inteligentes utilizando la mejor combinación (más barata) de opcodes. +Ejemplos de buenas prácticas para escribir contratos inteligentes: + +### Evite declarar variables como \`var + +```javascript +function payBonus() { + for (uint i = 0; i < empleados.longitud; i++) { + dirección empleado = empleados[i]; + uint bonus = calculateBonus(empleado); + empleado.enviar(bonus); + } + } +``` + +En el código anterior, el problema es que si el tipo de `i` se declarara como `var`, se tomaría como `uint8` porque éste es el tipo más pequeño que se requiere para contener el valor 0. Si el array tiene más de 255 elementos, el bucle no terminará con éxito, resultando en gas desperdiciado. Es mejor usar el tipo explícito `uint` para no tener sorpresas y tener límites más altos. **Evita declarar variables usando `var` si es posible.** + +### Bucle de matrices grandes + +```javascript +function soDifficultLooper() { + for (uint i = 0; i < largeArray.length; i++) { + address persona = largeArray[i]; + uint pago = difficultOperation(largeArray); + persona.enviar(pago); + } + } +``` + +Cada llamada a una función que modifica el estado del contrato inteligente tiene un coste de gas. Un bucle podría gastar mucho gas, lo que podría alcanzar fácilmente el límite de gas de una transacción o bloque. Si una transacción alcanza el límite de gas, se revertirán todos los cambios pero se seguirá pagando la tarifa. **Ten en cuenta los costes variables de gas cuando utilices bucles.** diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/index.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/index.md new file mode 100644 index 00000000..284fc9b0 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/index.md @@ -0,0 +1,88 @@ +--- +sidebar_position: 2 +title: Smart Bitcoin RBTC Token en RBTC - BTC a RBTC +tags: + - red principal + - red de pruebas + - fichas + - rbtc + - gas + - rsk + - portainjertos +sidebar_label: Ficha RBTC +--- + +RBTC es el token utilizado para [pagar por la ejecución](/concepts/rbtc/gas/) de transacciones en Rootstock. Puede [convertir BTC en RBTC](conversion.md) enviando BTC a través del [Powpeg](/concepts/powpeg/) (tanto en Testnet como en Mainnet), o utilizando el [faucet en Testnet](https://faucet.rootstock.io/), o a través de intercambios descentralizados. + +Ver [monederos soportados](/dev-tools/wallets/). + +[Obtener RBTC](https://rootstock.io/rbtc/#get-rbtc) + +## RBTC (Bitcoin inteligente en Mainnet) + +
+ + + + + + + + + + + + + + + + + + + + + + + +
Nombre de la fichaRBTC
Suministro total21.000.000 RBTC
Alimentación circulanteAPI
Tipo de contratoNativo(contrato Bridge)
Cómo conseguir + +
+ +## tRBTC (Bitcoin inteligente en Testnet) + + + + + + + + + + + + + + + + + + + + + + + + +
Nombre de la fichatRBTC
Suministro total21.000.000 tRBTC
Alimentación circulanteAPI
Tipo de contratoNativo(contrato Bridge)
Cómo conseguir + +
diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/networks.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/networks.md new file mode 100644 index 00000000..2bb33d3f --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rbtc/networks.md @@ -0,0 +1,217 @@ +--- +title: Conversión de BTC a RBTC y viceversa +sidebar_label: Redes +tags: + - rsk + - portainjertos + - rbtc + - conversión + - peg + - 2 vías + - clavija + - peg-out + - federación +description: Conversión de BTC a RBTC (peg-in) y de RBTC a BTC (peg-out) en Mainnet y Testnet. +sidebar_position: 303 +--- + +## Conversión de Mainnet + +En esta sección repasaremos los pasos necesarios para convertir BTC a RBTC y viceversa en las redes Bitcoin y Rootstock (RSK). + +:::tip[Tip] +La cantidad mínima de Bitcoin a convertir es de **0,005 BTC** para Mainnet. +::: + +### Conversor de BTC a RBTC + +Instrucciones sobre cómo hacer un peg-in en Mainnet. + +```mdx-code-block + + + 1. Obtener una dirección BTC con saldo + + - Cualquier monedero Bitcoin que soporte clave privada heredada (`p2pkh`) funciona para este paso. En esta sección, utilizaremos el monedero BTC de Electrum para conectarnos a BTC Mainnet. + 1. 1. Descargue el monedero desde [Electrum Website](https://electrum.org/) + 2. Instale Electrum https://electrum.org/ 2. Instale Electrum + Inicie Electrum + 4. Una vez iniciado Electrum, cree o importe un monedero + 5. 5. Vaya a la tercera pestaña "Recibir". Verá una dirección de Bitcoin Testnet como la siguiente: +
Create a Legacy (`p2pkh`) walletn
+ > Nota: Utilice un monedero Bitcoin antiguo (no Segwit) con una clave pública que empiece por `m` o `n`, y una clave privada con el prefijo `p2pkh`. + + + + 2. Enviar Bitcoin a la dirección de la Federación Rootstock + + Enviar Bitcoin a la dirección de la federación Rootstock + - La dirección de la federación Rootstock se obtiene realizando una llamada a un contrato inteligente en la red principal de Rootstock. Para realizar la llamada, debe tener instalado [MyCrypto](https://app.mycrypto.com/interact-with-contracts): + 1. 1. Seleccione la red Rootstock (RSK). + 2. Navegue a **MyCrypto** -> **Contratos**. + 3. Seleccione **Contratos existentes** y elija **Puente** en el menú desplegable. + 4. Haga clic en **getFederationAddress** para ejecutar la llamada. + Debería parecerse a la captura de pantalla siguiente: +
Get Rootstock Federation address from MyCrypto
+ Una vez que tenga la dirección de la Federación Rootstock, puede enviarle Bitcoin desde su dirección Bitcoin. + > Nota: Debe enviar una cantidad mínima de 0,005 BTC. + + + + 3. Esperar confirmaciones de BTC + + - Para asegurarnos de que la transacción se realiza correctamente, debemos esperar 100 confirmaciones de la red BTC. + > 100 bloques \* 10 minutos/bloque = 1000 minutos = 16,667 horas. Es decir, tardaremos aproximadamente 17 horas. + + + + 4. Obtener dirección RBTC con clave privada BTC + + - Puede obtener la dirección RBTC correspondiente a partir de su clave privada de BTC utilizando las [Rootstock Utils](https://github.com/rsksmart/utils). Si no desea compilar la utilidad, puede descargar la [última versión](https://github.com/rsksmart/utils/releases/latest). + > Nota: cuando introduzca la clave privada de Bitcoin no incluya _p2pkh:_ delante. + + + + 5. Comprobar el saldo de RBTC + + Puede comprobar el saldo de la dirección RBTC en Metamask, MyCrypto o cualquier [monedero compatible con Rootstock](https://blog.rootstock.io/noticia/rootstock-wallets/). + > Nota: Debe esperar un mínimo de 100 confirmaciones + un mínimo de 5 minutos para comprobar su saldo de RBTC. + + + +``` + +### Conversion RBTC a BTC + +Instrucciones sobre cómo hacer un peg-out de Mainnet. + +```mdx-code-block + + + 1. Obtener dirección BTC con clave privada RBTC + + Puedes obtener la dirección BTC correspondiente a tu clave privada RBTC utilizando la utilidad [Rootstock](https://github.com/rsksmart/utils). Si no desea compilar la utilidad, puede descargar la [última versión](https://github.com/rsksmart/utils/releases/latest). + + + + 2. Enviar RBTC a Rootstock Bridge Contract + + - Dirección del Contrato Puente Rootstock: `0x0000000000000000000000000000000001000006` + - Nota: La cantidad mínima a enviar debe ser de al menos 0,004 RBTC para Mainnet, el envío de cualquier cantidad por debajo de esto, fallará y los fondos serán reembolsados. El Límite de Gas de la transacción debe establecerse manualmente en 100.000 gas; de lo contrario, la transacción fallará. El Precio del Gas puede fijarse en 0,06 gwei (o el precio del gas sugerido por el monedero). + ![Personalizar Gas en Metamask antes de enviar transacción en Rootstock](/img/metamask-gas-limit.png) + + + + 3. Comprobar el saldo de la dirección BTC + + - Puede utilizar el monedero Electrum descargado anteriormente o desde cualquier explorador de Bitcoin para comprobar el saldo. + > Nota: El proceso de liberación en la red Bitcoin tarda 4000 confirmaciones de bloque de Rootstock y al menos 10 minutos más. + + + +``` + +## Conversión de Testnet + +En esta sección repasaremos los pasos para convertir t-BTC a tRBTC, y viceversa en las Testnets de Bitcoin y Rootstock. + +:::tip[Tip] +La cantidad mínima de Bitcoin a convertir es **0.005 tBTC** para Testnet. +::: + +### Conversion de tBTC a tRBTC + +Instrucciones para realizar un enclavamiento Testnet. + +```mdx-code-block + + + 1. Conectar un monedero a Bitcoin Testnet + + Recomendamos utilizar el monedero Electrum BTC para conectarse a Bitcoin Testnet. + - Descargue el monedero de + [Sitio web de Electrum](https://bitzuma.com/posts/a-beginners-guide-to-the-electrum-bitcoin-wallet/) + - Instale Electrum + - Inicie Electrum en modo Testnet + - Por ejemplo en MacOS: + `/Applications/Electrum.app/Contents/MacOS/Electrum --testnet` + - Una vez iniciado Electrum, cree o importe un monedero + - Vaya a la tercera pestaña, "Recibir". + Verá una dirección Bitcoin Testnet como la siguiente. + ![Crear un monedero heredado (`p2pkh`)](/img/legacy-private-key.png) + - Nota: El monedero Bitcoin tiene que ser heredado (no Segwit) cuya clave pública empiece por `m` o `n`, y la clave privada empiece por `p2pkh:` + ![Obtener una dirección Bitcoin Testnet en el monedero Electrum](/img/electrum-wallet.png) + + + + 2. Obtener Bitcoin de prueba de Testnet Faucet + + Hay varias opciones para obtener Bitcoin en Testnet. Nosotros utilizamos [https://testnet-faucet.mempool.co/](https://testnet-faucet.mempool.co/). + + + + 3. Enviar Bitcoin a la dirección de la Federación Rootstock + + - La dirección de la Federación Rootstock se obtiene haciendo una llamada de Contrato Inteligente en Testnet Rootstock. + - Para realizar la llamada, necesitará tener + [MyCrypto](https://app.mycrypto.com/interact-with-contracts) + instalado, seleccionar Rootstock Testnet en _"More Networks"_, y Navegar a _"MyCrypto -> Contracts -> Select Existing Contracts -> "Bridge" -> "getFederationAddress"_ para ejecutar la llamada. + - Debe parecerse a la siguiente captura de pantalla. + ![Obtener dirección de la Federación Rootstock desde MyCrypto](/img/mycrypto-federation-updated-10-07-2024.png) + Una vez que tenga la dirección de la Federación Rootstock, + puede enviarle Bitcoin desde su dirección Bitcoin. + - Nota: Necesita enviar una cantidad mínima de 0.01 tBTC para la conversión. + + + + 4. Obtener dirección tRBTC con clave privada tBTC + + - Puede obtener una dirección tRBTC correspondiente a partir de su clave privada tBTC utilizando [github.com/rsksmart/utils](https://github.com/rsksmart/utils). Si no desea compilar la utilidad, puede descargar la [última versión](https://github.com/rsksmart/utils/releases/latest). + - Nota: Cuando introduzcas la clave privada de Bitcoin no incluyas `_p2pkh:_` delante. + + + + 5. Comprobar el saldo de tRBTC en Testnet + + - Puede comprobar el saldo de la dirección tRBTC anterior en Metamask, MyCrypto o cualquier monedero Rootstock compatible con Testnet. + - Tiene que esperar un mínimo de 10 confirmaciones + un mínimo de 5 minutos para comprobar su saldo de RBTC. + + + +``` + +### Conversion de tRBTC a tBTC + +Instrucciones sobre cómo hacer una clavija Testnet. + +:::info[Note] +El proceso de liberación en la red Bitcoin tarda 10 confirmaciones de bloque Rootstock y al menos 10 minutos más. +::: + +```mdx-code-block + + + 1. Obtener la dirección tBTC con la clave privada tRBTC + + - Puedes obtener una dirección tBTC correspondiente a partir de tu clave privada tRBTC utilizando [github.com/rsksmart/utils](https://github.com/rsksmart/utils). Si no desea compilar la utilidad, puede descargar la [última versión](https://github.com/rsksmart/utils/releases/latest). + + + + 2. Enviar tRBTC a Rootstock Bridge Contract + + - Dirección del Contrato Puente Rootstock: `0x0000000000000000000000000000000001000006` + - **Nota importante**: La cantidad mínima a enviar debe ser **al menos** 0.004 tRBTC para Testnet, valores por debajo de eso serán rechazados y reembolsados al remitente. + - El límite de gas de la transacción debe establecerse manualmente en 100.000 gas; de lo contrario, la transacción fallará. + - El precio del gas puede fijarse en 0,06 gwei. + ![Personalizar Gas en Metamask antes de enviar transacción en Rootstock](/img/metamask-gas-limit.png) + + + + 3. Comprobar el saldo de la dirección tBTC en Bitcoin Testnet + + Puede utilizar el monedero Electrum descargado anteriormente o desde + cualquier explorador de Bitcoin para comprobar el saldo. + + + +``` diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rif-suite/index.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rif-suite/index.md new file mode 100644 index 00000000..1dc23624 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rif-suite/index.md @@ -0,0 +1,22 @@ +--- +sidebar_label: Suite RIF +sidebar_position: 3 +title: RIF Suite - Herramientas de código abierto +tags: + - rif + - ficha + - dApps + - productos +description: Herramientas y tecnologías de código abierto que hacen que construir sobre Bitcoin sea más rápido, fácil y gratificante. +--- + +Herramientas y tecnologías de código abierto que hacen que construir sobre Bitcoin sea más rápido, fácil y gratificante. + +## Conozca la Suite + +| Producto | Descripción | +| --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Sobrevuelo | Flyover es una forma rápida y segura para los usuarios de transferir BTC dentro y fuera del ecosistema Rootstock, donde se puede utilizar para interactuar con una serie de aplicaciones para enviar, ahorrar y gastar dinero. | +| RNS | RNS (RIF Name Service) sustituye las complicadas direcciones de criptomoneda por apodos fáciles de recordar, simplificando las transacciones de activos digitales. También facilita la integración de un protocolo de Identidad Soberana Propia en sus productos, lo que aumenta la seguridad y flexibilidad del usuario. . | +| Cartera | Lleve Bitcoin DeFi a sus usuarios con RIF Wallet, un monedero Bitcoin de código abierto con capacidades de contrato inteligente. De código abierto, totalmente programable y personalizable. | +| [Relé](/desarrolladores/integrate/rif-relay/) | RIF Relay simplifica los pagos de comisiones de gas al permitir a los usuarios pagar comisiones de transacción con cualquier token ERC20. Esto permite a los usuarios finales realizar transacciones utilizando un único activo, eliminando la complejidad y mejorando la integración. | diff --git a/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rif-suite/token/index.md b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rif-suite/token/index.md new file mode 100644 index 00000000..4260c571 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/01-concepts/rif-suite/token/index.md @@ -0,0 +1,110 @@ +--- +sidebar_label: Ficha RIF +sidebar_position: 400 +title: "Token RIF: Potenciando las aplicaciones descentralizadas" +tags: + - rif + - ficha + - erc677 +description: Información sobre el token RIF, dónde obtenerlo, cómo transferirlo y detalles técnicos sobre su estándar de token +--- + +El token Rootstock Infrastructure Framework (RIF) permite a cualquier poseedor de tokens consumir los servicios compatibles con [RIF Tools](/concepts/rif-suite/). + +## RIF (RIF Token en Mainnet) + + + + + + + + + + + + + + + + + + + + + + + + +
Nombre de la fichaRIF
Suministro total1.000.000.000 RIF
Dirección del contrato0x2acc95758f8b5f583470ba265eb685a8f45fc9d5
Tipo de contratoERC677
Cómo conseguir + +
+ +## tRIF (Token RIF en Testnet) + + + + + + + + + + + + + + + + + + + + + + + + +
Nombre de la fichatRIF
Suministro total1.000.000.000 tRIF
Contrato Dirección Testnet0x19f64674D8a5b4e652319F5e239EFd3bc969a1FE
Tipo de contratoERC677
Cómo conseguir + +
+ +## Billeteras + +Ver [monederos soportados](/dev-tools/wallets/). + +## Información técnica + +### Estándar de fichas ERC677 + +Una transacción de tokens [ERC20](https://github.com/ethereum/EIPs/issues/20) +entre una dirección normal/no contractual y un contrato son dos transacciones diferentes: Debes llamar a `approve` en el contrato de tokens y luego llamar a `transferFrom` en el otro contrato cuando quieras depositar tus tokens en él. + +[ERC677](https://github.com/ethereum/EIPs/issues/677) +simplifica este requisito y permite utilizar la misma función de transferencia. Los tokens ERC677 pueden enviarse llamando a la función `transfer` en el contrato de tokens sin diferencia si el receptor es un contrato o una dirección de cartera, ya que hay una nueva forma de notificar la transferencia al contrato receptor. + +Una transferencia de tokens ERC677 será igual que una transferencia ERC20. Por otro lado, si el receptor es un contrato, el contrato de tokens ERC677 intentará llamar a la función `tokenFallback` del contrato receptor. Si no hay ninguna función `tokenFallback` en el contrato receptor, la transacción fallará. + +### Métodos de transferencia RIF + +- Aprobar y transferir: + ```js + function aprobar(dirección _spender, uint256 _valor) public returns (bool) + function transfer(dirección _a, uint256 _valor) public returns (bool) + ``` + +- Transferir y llamar: + + ```js + function transfer(dirección _a, uint256 _valor, bytes datos) + ``` + + **Parámetros** + + - `_to: address`: Dirección del contrato. + - `_valor: uint256`: Cantidad de tokens RIF a enviar. + - `datos: bytes`: Firma de 4 bytes de la función a ejecutar, seguida de los parámetros de la función a ejecutar con codificados como matriz de bytes. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/02-requirements/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/02-requirements/index.md new file mode 100644 index 00000000..a3e1605e --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/02-requirements/index.md @@ -0,0 +1,156 @@ +--- +sidebar_label: Desarrollo Requisitos previos +sidebar_position: 2 +title: Requisitos previos +tags: + - rsk + - portainjertos + - requisitos previos + - configuración + - requisitos +description: Requisitos mínimos de hardware para Rootstock. +--- + +Esta guía proporciona instrucciones claras a los desarrolladores sobre las versiones de Solidity compatibles y las configuraciones necesarias para garantizar que sus contratos inteligentes se implementen en la red Rootstock. Consulte la sección [herramientas para desarrolladores](/dev-tools/) para obtener una lista de herramientas para construir en Rootstock. + +## Versión sólida + +- Versión solc compatible: `0.8.19`. + +## Nodo RPC + +- Interactúe con Rootstock mediante la [API RPC](https://rpc.rootstock.io/) + +:::tip[Get una clave API] +Vea cómo configurar la API RPC y obtener una [Clave API](/developers/rpc-api/setup). +::: + +## Configuración de la red + +Rellene estos valores para conectarse a la Rootstock Mainnet o Testnet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CampoRed principal de portainjertosRed de prueba de portainjertos
Nombre de la redRed principal de portainjertosRed de prueba de portainjertos
URL RPChttps://rpc.mainnet.rootstock.io/{YOUR_APIKEY}https://rpc.testnet.rootstock.io/{YOUR_APIKEY}
ChainID3031
SímboloRBTCtRBTC
Bloquear URL del exploradorhttps://explorer.rootstock.io/https://explorer.testnet.rootstock.io/
+ +## Direcciones contractuales + +- Consulte la lista de [Direcciones de contrato en Rootstock](/developers/smart-contracts/contract-addresses) + +### Vía de derivación + +Cuando utilice [BIP-44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki "Jerarquía multicuenta para monederos deterministas") compatible con el software de monedero +, deberá especificar una ruta de derivación. + +```text +Mainnet: m/44'/137'/0'/0/N +Testnet: m/44'/37310'/0'/0/N +``` + +:::info[Info] +Consulte la sección [Direcciones basadas en cuentas](/conceptos/direcciones basadas en cuentas/) para obtener más información o [cómo verificar la titularidad de la dirección](/desarrolladores/contratos-inteligentes/verificar-la-titularidad-de-la-dirección/). +::: + +## Instalar casco + +```bash +npm install --save-dev hardhat +``` + +:::tip\[Recommended] + +- Instale `hh` autocompletar para utilizar `hh` taquigrafía a nivel mundial. + +```bash +npm i -g hardhat-shorthand +``` + +- Utilice el [Kit de iniciación al casco](/developers/quickstart/hardhat) + +- Aprenda a escribir, interactuar, desplegar y probar contratos inteligentes en Rootstock utilizando [Hardhat](/developers/smart-contracts/hardhat) o [Foundry](/developers/smart-contracts/foundry/). + +::: + +## Herramientas de línea de comandos + +### Shell compatible con POSIX + +```mdx-code-block + + + Los terminales estándar como `cmd` o PowerShell pueden no soportar algunos comandos. Recomendamos instalar [Git para Windows](https://gitforwindows.org/) para Git Bash, que proporciona una experiencia más parecida a UNIX. Aquí tienes un [tutorial sobre Git Bash](https://www.atlassian.com/git/tutorials/git-bash). + + + Terminal estándar. + + +``` + +### Instalación de Node.js y NPM + +````mdx-code-block + + + - Node v18 o posterior. + - Para la instalación, utilice [NVM install script](https://github.com/nvm-sh/nvm#install--update-script). + + + 1. Descargue el instalador de Node.js desde [Descargas de Node.js](https://nodejs.org/en/download). + 2. Ejecuta el instalador y sigue las instrucciones en pantalla. + 3. Abra Command Prompt o PowerShell y compruebe las versiones con `node -v` y `npm -v`. + - Véase Shell compatible con Posix. + + + 1. Instala Homebrew (si no está instalado): + ```bash + /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh) + ``` + 2. Instala Homebrew. Instala Node.js y npm con `brew install node` + 3. Comprueba las versiones en el Terminal con `node -v` y `npm -v` + + + 1. 1. Abre un terminal. + 2. Actualiza el gestor de paquetes con sudo apt update + 3. Instala Node.js y npm con sudo apt install nodejs npm + 4. Comprueba las versiones en el terminal con `node -v` y `npm -v` + + +```` + +## Configuración opcional + +- [Foundry](/desarrolladores/contratos inteligentes/foundry) +- [Remix](https://remix.ethereum.org/) diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/02-overview/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/02-overview/index.md new file mode 100644 index 00000000..aea228e9 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/02-overview/index.md @@ -0,0 +1,134 @@ +--- +sidebar_label: Visión general de Blockchain +sidebar_position: 200 +title: Primeros pasos en el desarrollo de portainjertos (RSK) +description: Aprenda a interactuar con Rootstock en su navegador web, a consultar las transacciones de Rootstock y a desarrollar e implementar su primer contrato inteligente en la red Rootstock. +tags: + - arranques rápidos + - rsk + - portainjertos + - blockchain + - monederos de navegador + - desarrolladores + - principiantes +--- + +Conozca Rootstock, cómo permite contratos inteligentes en Bitcoin y su compatibilidad con Ethereum y otras plataformas. + +## ¿Qué es el portainjertos? + +La pila tecnológica completa de Rootstock está construida sobre Bitcoin: +Desde los contratos inteligentes de Rootstock hasta el marco de infraestructura de Rootstock. +La pila está diseñada para crear un sistema financiero más justo e inclusivo. + +> Véase [La pila](/conceptos/fundamentos/pila/) + +Bitcoin, es un almacén y transferencia de valor. +La cadena de bloques es segura porque los mineros, con elevados costes de infraestructura y energía, crean nuevos bloques que se añaden a la cadena de bloques cada 10 minutos. +Cuanta más potencia de hash proporcionen, más segura será la red. +Rootstock es la primera plataforma de contratos inteligentes de código abierto impulsada por la red bitcoin. +El objetivo de Rootstock es añadir valor y funcionalidad al ecosistema bitcoin permitiendo contratos inteligentes, +pagos casi instantáneos y una mayor escalabilidad. +RIF es un conjunto todo en uno de aplicaciones y servicios de infraestructura abiertos y descentralizados que permiten un desarrollo más rápido, +sencillo y escalable de aplicaciones distribuidas (dApps) dentro de un entorno blockchain unificado. + +Rootstock está conectado a Bitcoin en términos de cómo se minan sus bloques, +y también en términos de una moneda común. +Rootstock también es compatible con Ethereum en términos de su máquina virtual (que ejecuta contratos inteligentes), +así como la RPC (API externa) que expone. +Veamos brevemente cada una de estas áreas. + +## Powpeg + +El segundo punto de contacto es el [Powpeg](/conceptos/powpeg/). +Este componente conecta ambas redes para permitir la transferencia de bitcoins a Rootstock, +permitiendo así a los desarrolladores interactuar con contratos inteligentes. +Pagan el gas utilizando el mismo bitcoin, el bitcoin inteligente. + +
+
+
+ +Para ello, se envían bitcoin a una dirección especial, +, donde quedan bloqueados en la red bitcoin. +A continuación, en la misma dirección de la red Rootstock, +, se libera ese mismo bitcoin para que el usuario lo utilice en la red Rootstock. +Esto se denomina peg-in. +Puede realizar la operación inversa, denominada peg-out, +enviando su bitcoin a una dirección especial de la red Rootstock, +y recibiendo su bitcoin de vuelta en la red bitcoin. + +## Diferencias con Rootstock y Ethereum + +Rootstock no es 100% compatible con Ethereum: Tiene diferencias en la forma en que se calculan las sumas de comprobación, +la ruta de derivación que utiliza, y cómo se calcula el gas. + +### Diferencias de suma de comprobación + +- Las distintas redes compatibles con Ethereum se diferencian entre sí mediante "identificadores de cadena". +- Cada red blockchain tiene su propio ID de cadena único. +- Rootstock utiliza el ID de la cadena al calcular las sumas de comprobación de sus direcciones, mientras que Ethereum no lo tiene en cuenta. +- Las sumas de comprobación en ambas redes se representan utilizando mayúsculas (mayúsculas y minúsculas), por lo que la "misma" dirección no pasará las validaciones de sumas de comprobación tanto en Rootstock como en Ethereum. + +### Diferencias en la vía de derivación + +Recordar o almacenar claves privadas para sus monederos criptográficos puede ser un gran reto, incluso para los técnicos. +Esto se debe a que estas claves son esencialmente números extremadamente grandes. +Así que para facilitar las cosas, la comunidad criptográfica ha ideado una técnica llamada "monederos HD", en la que se utiliza una frase semilla (un conjunto de palabras de diccionario elegidas al azar), más una "ruta de derivación". Rootstock y Ethereum tienen diferentes rutas de derivación, por lo tanto, la misma frase semilla resulta en un conjunto diferente de claves y direcciones entre Rootstock y Ethereum. + +### Diferencias de gas + +El EVM y el RVM son compatibles en el sentido de que admiten los mismos op-codes y, por tanto, pueden ejecutar los mismos contratos inteligentes. +Sin embargo, el precio de cada op-code (medido en unidades conocidas como gas) es diferente entre EVM y RVM, por lo que el gas total consumido en varias transacciones es diferente. +Además, las unidades de gas se multiplican por el precio del gas para calcular el coste de la transacción. +Dado que el precio del gas de Rootstock está denominado en RBTC y el precio del gas de Ethereum está denominado en Ether, existe otra diferencia entre los precios del gas en Rootstock y Ethereum. + +## Contratos inteligentes compatibles con EVM + +Si está familiarizado con el desarrollo de contratos inteligentes o el desarrollo de dApps utilizando solidity, web3 y otras tecnologías compatibles, le encantará saber que la máquina virtual de Rootstock (RVM) es compatible con la máquina virtual de Ethereum (EVM). +Así que usted puede utilizar el mismo código, herramientas y bibliotecas cuando se desarrolla con Rootstock también. +Por lo tanto, las habilidades de desarrollo de contratos inteligentes y aplicaciones a las que está acostumbrado se transferirán muy bien. + +> Consulte la versión de Solidity compatible en [requisitos](/developers/requirements/) + +### Herramientas + +- [Hardhat](https://hardhat.org/docs) es un entorno de desarrollo de Ethereum diseñado para profesionales. Se utiliza principalmente en el desarrollo de contratos inteligentes para la blockchain de Ethereum. + Consulte el [Hardhat Overview](/dev-tools/hardhat/) para una visión general de cómo se utiliza en Rootstock. + +- [Metamask](https://metamask.io/) es un monedero de criptomoneda con extensión de navegador o aplicación móvil, + que permite a los usuarios interactuar con la blockchain de Rootstock, + incluido el envío de RBTC, el envío de tokens basados en Rootstock como RIF, + e interactuar con contratos inteligentes desplegados en la red Rootstock. + Consulte cómo [configurar MetaMask para conectarse a Rootstock](/dev-tools/wallets/metamask/). + +- [Mocha](https://mochajs.org/) es un popular marco de pruebas de JavaScript que se ejecuta en Node.js. + Consulte [Testing Smart Contracts](/developers/smart-contracts/hardhat/test-smart-contracts/) para ver cómo usarlo para probar sus contratos inteligentes en Rootstock. + +- [Solidity](https://docs.soliditylang.org/) es el lenguaje de programación más popular para implementar contratos inteligentes. + El bytecode y la ABI que genera el compilador de Solidity, `solc`, se pueden utilizar para implementar e interactuar con contratos inteligentes en Rootstock, gracias a la compatibilidad entre RVM y EVM. + +> Para obtener una lista completa de herramientas, consulte la sección [Dev Tools](/dev-tools/). + +## RPC JSON compatible con Ethereum + +El conjunto de llamadas a procedimientos remotos (RPC) que soporta Rootstock es en gran medida el mismo que las RPC soportadas por Ethereum. +Se trata de otra capa de compatibilidad, además de la implementación de la máquina virtual, que permite utilizar las mismas herramientas y bibliotecas. + +## Minería fusionada + +Los mineros de bitcoin realizan lo que se conoce como [minería fusionada](/concepts/merged-mining/), +asegurando ambas redes con la misma infraestructura y consumo energético. + +
+
+
+ +Crean bloques en la red bitcoin cada 10 minutos, incluyendo la transferencia de bitcoin desde diferentes direcciones, y en el proceso crean nuevos bitcoins. +En Rootstock, los bloques se crean cada 30 segundos, para asegurar la ejecución de contratos inteligentes. +En el proceso no se acuñan nuevas monedas, pero sí se obtiene una recompensa de la minería fusionada. +Echa un vistazo a [rootstock.io/mine-btc-with-rootstock](https://rootstock.io/mine-btc-with-rootstock/) para obtener más información sobre la minería. + +:::info[Note] +El tiempo entre bloques en cada red indicado anteriormente son valores aproximados. +::: diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/03-browser/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/03-browser/index.md new file mode 100644 index 00000000..9a817e30 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/03-browser/index.md @@ -0,0 +1,130 @@ +--- +sidebar_label: Uso del patrón en el navegador +sidebar_position: 300 +title: Uso de Rootstock con una extensión del navegador +description: Aprenda a interactuar con Rootstock en su navegador web, a consultar las transacciones de Rootstock y a desarrollar e implementar su primer contrato inteligente en la red Rootstock. +tags: + - arranques rápidos + - rsk + - portainjertos + - blockchain + - monederos de navegador + - desarrolladores + - principiantes +--- + +Como Rootstock es una cadena de bloques con capacidades de contrato inteligente, es posible crear aplicaciones descentralizadas (dApps) con ella. +La mayoría de las dApps son aplicaciones web a las que se accede con un navegador de Internet normal, como Chrome. +Sin embargo, las interacciones blockchain requieren algún software adicional, que viene en forma de extensiones del navegador. +Estas extensiones de navegador insertan un objeto **web3 provider**, con las partes Javascript de la aplicación web utilizadas para interactuar con la blockchain, formando parte integral de la arquitectura de la dApp. + +> Ten en cuenta que estas extensiones de navegador almacenan tus claves privadas, +> y las utilizan para firmar transacciones. Así que manténgalas seguras. + +:::note[Rootstock Carteras] +Hay varias extensiones de navegador que puede utilizar para interactuar con la blockchain Rootstock, esto incluye: [MetaMask](https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn). Para obtener una lista completa de monederos, consulte la sección [Dev Tools](/dev-tools/). +::: + +Dado que este es un comienzo rápido, no vamos a ir a través de todos ellos - sólo MetaMask. + +Hay algunas complejidades ocultas que hemos pasado por alto en el contenido anterior para que +pueda configurarse y ponerse en marcha lo antes posible. +Si quieres profundizar más, aquí tienes algunos recursos que te recomendamos. + +## Instalar Metamask + +MetaMask es la extensión de navegador más popular con capacidades de proveedor web3. +Permite a los usuarios comprar, almacenar, enviar e intercambiar tokens. + +Metamask también le proporciona un depósito de claves, un inicio de sesión seguro, un monedero de tokens y un intercambio de tokens: todo lo que necesita para gestionar sus activos digitales. + +Abra el navegador Chrome e instale la extensión desde [Chrome store](https://chrome.google.com/webstore/detail/nkbihfbeogaeaoehlefnkodbefgpgknn). + +Este breve vídeo muestra cómo descargar e instalar MetaMask en tu navegador, y también cómo crear una cartera para almacenar tus criptoactivos. + +
+ +
+ +## Criptografía + +## Claves privadas y claves públicas + +En el software de monedero, generalmente se ven "cuentas" representadas por direcciones en la red blockchain. +En el caso de Rootstock, es `0x` seguido de una serie de caracteres hexadecimales, por ejemplo, `0xdfc0e6361fd1846a223e2d7834a5ebd441a16dd4`. +Hay cierta complejidad oculta detrás de esto, relacionada con la criptografía, que es necesaria para asegurar la cuenta y todas las transacciones de blockchain que realiza. + +- Empiezas con una clave privada, que es esencialmente un número extremadamente grande, y debe ser generado aleatoriamente. + Debes mantener la clave privada en secreto, porque es la que se utiliza para firmar las transacciones. +- A partir de la clave privada se genera una clave pública, que también es un número muy grande. + No es necesario mantenerla en secreto, porque otros miembros de la red blockchain la utilizan para verificar las transacciones. +- Una dirección se genera a partir de la clave pública, y es la cadena hexadecimal que ves en el software de tu monedero. + +### Frases semilla + +Cuando abras MetaMask por primera vez después de instalarlo, se te pedirá que lo inicialices utilizando una frase semilla. +Si ya lo has hecho antes, puedes utilizar tu propia frase semilla. Si no, ¡vamos a generar una nueva! + +> Para generar una nueva frase semilla, deberá crear un nuevo monedero. +> Consulte los pasos anteriores para crear un nuevo monedero. + +La mayoría de los usuarios de blockchain manejan una o más cuentas, y puede ser bastante difícil recordar el valor de las claves criptográficas - esos números tan grandes - ¡necesitarás una memoria sobrehumana! +La **frase semilla** es actualmente el método más popular utilizado para generar, almacenar, recordar y recuperar claves para criptocarteras, y es algo accesible para el usuario medio. + +También es el método por defecto utilizado por MetaMask (y muchos otros monederos). +En pocas palabras, toma una secuencia generada aleatoriamente de palabras del diccionario. +El monedero utiliza esta secuencia de palabras para generar no uno, sino múltiples conjuntos de claves criptográficas. +Así es como MetaMask es capaz de soportar múltiples cuentas utilizando una única frase semilla. + +Este proceso se describe detalladamente en la norma técnica BIP-44. +Esto garantiza que el funcionamiento de las frases semilla sea el mismo entre múltiples criptocarteras, lo que permite que la misma frase sea portátil. + +## Configurar una red personalizada para Rootstock Testnet + +MetaMask viene preconfigurado con conexiones para redes Ethereum. +Vamos a utilizar su función de redes personalizadas para añadir una conexión a una red Rootstock. + +
+ +
+ +Después de crear la red personalizada para la Testnet de Rootstock, debería poder interactuar con los contratos inteligentes desplegados en la Testnet de Rootstock. +También debería ver sus saldos en tRBTC (Testnet RBTC). +Actualmente es cero, lo que significa que no podemos enviar ninguna transacción a la blockchain, así que vamos a conseguir algunas usando el grifo RBTC. + +
+ +
+ +Ahora debería tener un saldo de tRBTC, ¡y podrá enviar transacciones en la Testnet de Rootstock! + +## Configurar token personalizado para tRIF + +El Marco de Infraestructura del Rootstock (RIF) incluye múltiples servicios para aplicaciones descentralizadas. +Estos servicios pueden pagarse utilizando el token RIF. +Vamos a configurar MetaMask para que conozca el token RIF. +Utilizaremos tRIF como símbolo del token, ya que estamos en la Testnet de Rootstock. + +
+ +
+ +Ahora que MetaMask tiene el token RIF configurado, vamos a obtener algunos tokens de prueba utilizando el grifo RIF. + +
+ +
+ +Ahora deberías tener un saldo de tRIF, ¡y podrás utilizar los servicios de RIF en la Rootstock Testnet! + +### Lecturas complementarias + +- [Cómo configurar Metamask](/dev-tools/wallets/metamask/) +- [Direcciones basadas en cuentas en Rootstock](/concepts/account-based-addresses/) +- [Acerca del token RIF](/concepts/rif-suite/token/) +- [Acerca de la criptomoneda RBTC](/conceptos/rbtc/) +- [Acerca del gas](/concepts/rbtc/gas/) +- [Acerca de los servicios RIF](https://www.rifos.org/) +- [Sobre BIP-44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) +- [Acerca de EIP-20](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md) +- [Generación de claves asimétricas](https://en.wikipedia.org/wiki/Public-key_cryptography) diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/04-transactions/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/04-transactions/index.md new file mode 100644 index 00000000..3a1c69d0 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/04-transactions/index.md @@ -0,0 +1,101 @@ +--- +title: Explorar las transacciones de portainjertos +sidebar_position: 400 +sidebar_label: Transacciones de portainjertos +description: Aprenda a interactuar con Rootstock en su navegador web, a consultar las transacciones de Rootstock y a desarrollar e implementar su primer contrato inteligente en la red Rootstock. +tags: + - arranques rápidos + - rsk + - portainjertos + - blockchain + - monederos de navegador + - desarrolladores + - principiantes +--- + +En la [sección anterior](/developers/blockchain-essentials/overview/), configuramos una extensión del navegador que es un monedero criptográfico, MetaMask. Nos conectamos a la red de pruebas de Rootstock y la cargamos con la criptomoneda de Rootstock, RBTC, y un token basado en Rootstock, RIF. + +> Tenga en cuenta que, si aún no ha realizado este paso, le recomendamos que vuelva atrás y lo complete primero. Véase: [Uso de Rootstock en el navegador](/developers/blockchain-essentials/browser/). + +## Explorador de bloques + +Ahora que ya estamos preparados, ¡exploremos algunas transacciones! +La red Rootstock es un **libro contable público inmutable**. +Vamos a diseccionar esa frase: + +- \*\*Libro de contabilidad: Una lista ordenada de transacciones registradas de alguna forma +- **Inmutable**: La forma en que este libro se registra y almacena significa que cualquier transacción existente no puede ser borrada o modificada. También se puede considerar un libro de contabilidad "sólo para añadir". +- **Público**: El contenido de este libro de contabilidad es abierto y transparente, por lo que cualquier persona conectada a esta red puede ver todas y cada una de las transacciones de la historia. + +Aquí es donde entran en juego los exploradores de bloques. +Son un tipo especial de software que se conecta a una red blockchain y muestra los datos de este libro de contabilidad público inmutable. + +Dado que es abierto y transparente, nada impide que varios exploradores de bloques muestren los datos en una única cadena de bloques. Este es el caso de Rootstock, y existen varios exploradores de bloques. Aquí utilizaremos el canónico, pero siéntase libre de utilizar otros exploradores de bloques. + +### Ver cuenta en el explorador de bloques + +Vea este breve vídeo en el que se muestra cómo ver una cuenta en el explorador de bloques. + +
+ +
+ +Para la red principal de Rootstock, iríamos a [`explorer.rootstock.io`](https://explorer.rootstock.io/). +Sin embargo, como actualmente estamos conectados a la red de pruebas de Rootstock, iremos a [`explorer.testnet.rootstock.io`](https://explorer.testnet.rootstock.io/). + +## Transferencia tRBTC + +Hasta ahora, no has realizado ninguna transacción desde tu dirección. Las transacciones que ves cuando ves la dirección en el explorador de bloques se hicieron desde otras direcciones (en este caso, un par de grifos de Testnet). Ahora es el momento de que inicies tus propias transacciones. + +Vea este breve vídeo en el que se muestra **cómo transferir tRBTC de una cuenta a otra**. + +
+ +
+ +Empezaremos transfiriendo criptomoneda desde tu dirección a la dirección del grifo. + +## Transferencia tRIF + +Vea este breve vídeo en el que se muestra **cómo transferir la tRIF de una cuenta a otra**. + +
+ +
+ +## Disminución del saldo de RBTC + +Es posible que haya observado que al enviar tRBTC, el saldo de tRBTC disminuyó en **un poco más** que la cantidad que envió. También habrás observado que cuando enviaste tRIF, el saldo de tRBTC también disminuyó en una pequeña cantidad, aunque en esa transacción sólo se enviaron tRIF. + +Lo habrá visto en las pantallas de confirmación de transacciones al confirmar cada transacción. + +Esto **no es un error**, es simplemente un aspecto fundamental del funcionamiento de las redes blockchain: cada vez que añades una transacción a la blockchain, debes pagar a la red una tarifa para compensar sus costes computacionales. + +## Ver transacciones + +Cuando realizaste cada una de las transacciones, deberías haber recibido notificaciones en ventanas emergentes. + +Sin embargo, si te has perdido esto, no te preocupes, también puedes encontrarlo en el historial de transacciones dentro de MetaMask. Para ello, dentro de la pantalla principal de MetaMask, haz clic en la pestaña "Actividad". Verás la lista de las transacciones. + +A continuación, haga clic en cualquier transacción, y haga clic en el botón de flecha junto al botón de copia llamado ID de transacción, esto le lleva al [Testnet explorer](https://explorer.testnet.rootstock.io) + +Si ha hecho clic en la notificación emergente, o si la encuentra dentro de la pestaña "Actividad", de cualquier forma, esto debería abrir el explorador de bloques con la transacción seleccionada. + +Para la transacción de la transferencia tRBTC, debería ver esto + +Observará que esta transacción tiene un importe. + +Para la transacción de la transferencia tRIF, debería ver esto + +Observarás que esta transacción tiene un importe cero, pero emite algunos eventos, lo cual se debe a que el contrato inteligente del token RIF se encarga de ello. + +## Ver estadísticas de red + +Hasta ahora hemos comprobado direcciones y transacciones individuales. Se trata de información muy detallada y específica. ¿Y si lo que busca es una visión general? ¿Una vista de pájaro de la blockchain de Rootstock en su conjunto? + +Para ello, no utilizaremos el explorador de bloques de portainjertos, sino la página de estadísticas de portainjertos. + +[Estadísticas de Rootstock](https://stats.rootstock.io) +] +Aquí podemos ver algunas cifras muy importantes, como la duración media de los bloques y la tasa de hash de minería combinada, así como otros indicadores técnicos importantes de la red Rootstock. +Un indicador clave a tener en cuenta es la duración media de los bloques, que debería ser de aproximadamente 33 segundos. Otro indicador clave a tener en cuenta es el porcentaje de la tasa de hash de la red Bitcoin que es minería fusionada Rootstock. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/index.md new file mode 100644 index 00000000..56e475c6 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/03-blockchain-essentials/index.md @@ -0,0 +1,22 @@ +--- +sidebar_label: Fundamentos de Blockchain +sidebar_position: 3 +title: Fundamentos de la cadena de bloques Rootstock +tags: + - arranques rápidos + - rsk + - portainjertos + - blockchain + - monederos de navegador + - desarrolladores + - principiantes +description: Aprenda a interactuar con Rootstock en su navegador web, a consultar las transacciones de Rootstock y a desarrollar e implementar su primer contrato inteligente en la red Rootstock. +--- + +Conozca Rootstock, cómo permite contratos inteligentes en Bitcoin y su compatibilidad con Ethereum y otras plataformas. + +| Título | Descripción | +| ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| [Visión general de Rootstock](/developers/blockchain-essentials/overview/) | Conozca el portainjerto y su ecosistema. | +| [Uso de Rootstock en el navegador](/developers/blockchain-essentials/browser/) | Aprenda a interactuar con Rootstock en su navegador web, a consultar las transacciones de Rootstock y a desarrollar e implementar su primer contrato inteligente en la red Rootstock. | +| [Exploración de las transacciones de Rootstock](/developers/blockchain-essentials/transactions/) | Aprenda a interactuar con Rootstock en su navegador web, a consultar las transacciones de Rootstock y a desarrollar e implementar su primer contrato inteligente en la red Rootstock. | diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/hardhat.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/hardhat.md new file mode 100644 index 00000000..8340bcfe --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/hardhat.md @@ -0,0 +1,161 @@ +--- +sidebar_label: Uso del casco +sidebar_position: 400 +title: Rizoma Casco DApp +description: Tanto si eres un desarrollador experimentado como si acabas de iniciar tu andadura en el desarrollo de contratos inteligentes, el kit de inicio hardhat proporciona una base sólida para crear aplicaciones descentralizadas (dApps) en la red Rootstock. +tags: + - rsk + - portainjertos + - tutoriales + - desarrolladores + - casco + - inicios rápidos + - dApps + - contratos inteligentes +--- + +Tanto si eres un desarrollador experimentado como si acabas de iniciar tu andadura en el desarrollo de contratos inteligentes, el kit de inicio hardhat proporciona una base sólida para crear aplicaciones descentralizadas (dApps) en la red Rootstock. + +Rootstock es totalmente compatible con Ethereum. Aporta la potencia de los contratos inteligentes a Bitcoin, lo que permite a los desarrolladores aprovechar la seguridad de Bitcoin al tiempo que se benefician del ecosistema de Ethereum. + +## Requisitos previos + +Antes de iniciar la dApp, asegúrese de tener los siguientes requisitos previos: + +1. **Familiaridad con contratos inteligentes:** + - Si es nuevo en el mundo de los contratos inteligentes, considere la posibilidad de aprender los conceptos básicos. Entender cómo funcionan los contratos inteligentes mejorará su experiencia con el desarrollo de Rootstock. + +2. **Node.js y Hardhat Instalado:** + - Asegúrese de que tiene Node.js instalado en su sistema. Consulte la sección [prerequisites](/developers/requirements/#installing-nodejs-and-npm). + +3. **Instalar la taquigrafía del casco:** + +- Recomendamos instalar la función de autocompletar `hh` para utilizar la abreviatura `hh` de forma global. + + ```bash + npm i -g hardhat-shorthand + ``` +- Para más detalles, consulte su [guía oficial](https://hardhat.org/guides/shorthand.html). + +4. **Configuración de Metamask con portainjertos:** + +- Instale la extensión de navegador Metamask si aún no lo ha hecho. +- Configure Metamask para conectarse a la red Rootstock. Visite [MetaMask Integration on the Rootstock Dev Portal] (/dev-tools/wallets/metamask/). + +5. **Conocimientos básicos de Hardhat:** + +- Se recomienda estar familiarizado con los conceptos básicos y las funcionalidades de Hardhat. Si no conoce Hardhat, consulte la [Guía de Hardhat del Rootstock](/desarrolladores/contratos-inteligentes/hardhat/). + +:::tip[Rootstock Curso para desarrolladores de Blockchain]. + +Aprenda a escribir, probar, asegurar, desplegar y verificar contratos inteligentes en la red blockchain de Rootstock. Inscríbase en el [Rootstock Blockchain Developer Course](/resources/courses/). +::: + +## Configuración de la dApp de ejemplo + +### Clonar el repositorio + +Abre tu terminal o símbolo del sistema y ejecuta el siguiente comando para clonar el repositorio de GitHub: + +```bash +git clone https://github.com/rsksmart/rootstock-hardhat-starterkit.git +``` + +### Instalar dependencias + +Navegue hasta la carpeta del repositorio clonado: + +```bash +cd portainjertos-hardhat-starterkit +``` + +Instale todas las dependencias necesarias utilizando npm: + +```bash +npm instalar +``` + +### Obtención de las URL RPC de Rootstock Testnet y Mainnet + +Esta sección le guiará a través de la adición de Rootstock Testnet y Mainnet RPC URLs a su entorno de desarrollo. Estas URL son esenciales para conectar su aplicación a la red Rootstock e interactuar con contratos inteligentes. + +Hay dos formas de obtener URLs RPC: + +#### Uso de URL RPC públicas + +- Visite [Integración de MetaMask en el portal de desarrollo de Rootstock] (/dev-tools/wallets/metamask/). Esta guía proporciona instrucciones para configurar MetaMask para Rootstock. Mientras sigue estos pasos, preste especial atención a las secciones sobre la adición de redes personalizadas. Encontrará las URL RPC para Rootstock Testnet y Mainnet. + +#### Uso de la API RPC + +- Cree una cuenta en [Rootstock RPC API](https://rpc.rootstock.io/). Una vez iniciada la sesión, vaya a su panel de control y copie la clave de API. + +### Añadir las URL a su proyecto + +Después de obtener las URLs RPC, crea un archivo llamado `.env` en el directorio raíz de tu proyecto (importante: este archivo no debe ser enviado al control de versiones). Añade las variables de entorno necesarias al archivo `.env`: + +``` +PRIVATE_KEY: Su clave privada (por ejemplo, de los detalles de su cuenta de Metamask). +RSK_MAINNET_RPC_URL: La URL RPC para la red principal de Rootstock. +RSK_TESTNET_RPC_URL: La URL RPC para la red de prueba de Rootstock. +``` + +## Despliegue de un contrato de token ERC721 + +Esta sección utiliza el marco de desarrollo Hardhat para desplegar un token ERC721 (un token no fungible) en la red Rootstock. + +Ejecute el siguiente comando, sustituyendo `` por `rskTestnet` o `rskMainnet` en función del entorno de despliegue que desee: + +```bash +hh deploy --red --etiquetas 721 +``` + +Ejemplo de comando: + +```bash +hh deploy --network rskTestnet --tags 721 +``` + +Este comando compilará sus contratos Solidity, generará información de tipo y desplegará su contrato ERC721 en la red Rootstock especificada. La salida mostrará la dirección del contrato desplegado y la cantidad de gas utilizado. + +El comando anterior devolverá una salida similar a la siguiente: + +```bash +Generando tipados para: 36 artefactos en dir: typechain-types para objetivo: ethers-v6 +¡Generados 106 tipos con éxito! +Compilados 34 archivos Solidity con éxito (objetivo evm: paris). +desplegando "MockERC721" (tx: 0x9ad1dbc047b78594cf2cad105ded54c851fc0895ae69e4381908fecedd0ee3fc)...: desplegado en 0x2E027a3a05f3de6777B23397a50a60ecd04fe34C con 2849621 gas +``` + +## Interactuar con el contrato - Acuñar un token + +En el despliegue del contrato, puedes interactuar con él utilizando el comando `erc721-mint` de Hardhat. Este comando te permite acuñar (crear) nuevos tokens ERC721. + +### Acuñación de una ficha: + +En su terminal, ejecute el siguiente comando, sustituyendo los marcadores de posición por valores reales: + +```bash +hh erc721-mint \ + --contract \ + --recipient \ + --network rskTestnet +``` + +Ejemplo de comando: + +```bash +hh erc721-mint --contract 0x2E027a3a05f3de6777B23397a50a60ecd04fe34C --recipient 0xB0f22816750851D18aD9bd54c32C5e09D1940F7d --network rskTestnet +``` + +- ``: Sustitúyalo por la dirección de su contrato ERC721 desplegado obtenida en el paso anterior. +- ``: Sustitúyelo por la dirección del monedero para recibir el token recién acuñado. +- ``: Sustitúyalo por `rskTestnet` o `rskMainnet`, dependiendo de la red en la que esté desplegado su contrato. + +Este comando iniciará una transacción para acuñar un nuevo token ERC721 y enviarlo a la dirección del destinatario especificada. + +La salida mostrará los detalles de la transacción: + +```bash +Hash de la transacción: 0xa127ff008e20d8b3944cecb374f28535cd84555881cde157708ec5545603a4e4 +Transacción confirmada +``` diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/index.md new file mode 100644 index 00000000..75ec776d --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/index.md @@ -0,0 +1,101 @@ +--- +sidebar_label: Arranques rápidos +sidebar_position: 4 +title: Arranques rápidos +tags: + - rsk + - portainjertos + - principiante + - inicios rápidos + - desarrolladores + - avanzado + - puerto al portainjertos + - tutoriales +description: Inicio rápido, demos y kits de inicio para desarrollar en Rootstock. +--- + +```mdx-code-block + + + + + + + + + + +``` diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/rootstock-etherspot.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/rootstock-etherspot.md new file mode 100644 index 00000000..bd8ef66c --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/rootstock-etherspot.md @@ -0,0 +1,157 @@ +--- +sidebar_label: Abstracción de cuentas +sidebar_position: 500 +title: Abstracción de cuenta usando Etherspot Prime SDK +description: En esta guía, aprenderás a utilizar el SDK de Etherspot Prime para desplegar una dApp de Abstracción de Cuenta en la red Rootstock. Siguiendo estos pasos, permitirás a tus usuarios interactuar con tu dApp sin gestionar claves privadas directamente. +tags: + - rsk + - portainjertos + - desarrolladores + - inicios rápidos + - etherspot + - dApps + - abstracción de cuentas +--- + +En esta guía, aprenderás a utilizar el SDK de Etherspot Prime para desplegar una dApp de Abstracción de Cuenta en la red Rootstock. +Siguiendo estos pasos, permitirás a tus usuarios interactuar con tu dApp sin gestionar claves privadas directamente. + +## Requisitos previos + +- Asegúrese de que git está instalado +- Conocimientos básicos de React y JavaScript +- Node.js y npm (o yarn) instalados en su máquina +- Un editor de código de su elección (por ejemplo, Visual Studio Code) +- Familiaridad con el [Wagmi starter kit](https://github.com/rsksmart/rsk-wagmi-starter-kit/tree/aa-sdk) + +:::info[Info] +_Esta guía asume que ya tienes un [Wagmi starter kit](https://github.com/rsksmart/rsk-wagmi-starter-kit/tree/aa-sdk) configurado._ +::: + +## Comprender la abstracción de cuentas + +La abstracción consiste en ocultar datos innecesarios sobre un "objeto" para simplificar el sistema y mejorar la eficiencia. Aplicada a la tecnología blockchain de Ethereum, la abstracción de cuentas pretende crear un único tipo de cuenta que incluya solo los aspectos relevantes. + +Existen dos tipos principales de cuentas de Ethereum: Cuentas de Usuario (EOA) y Contratos. Las cuentas de usuario están diseñadas para particulares y se controlan mediante claves privadas. Estas cuentas, también conocidas como cuentas de propiedad externa (EOA), pueden mantener un saldo en Ether y realizar transacciones con otras EOA utilizando Ether y otros tokens respaldados por el ERC. + +Por otro lado, los Contratos están controlados por código y pueden realizar diversas funciones, como interactuar con cuentas externas e iniciar actividades como el intercambio de tokens o la creación de nuevos contratos. + +Con la abstracción de cuentas, una sola cuenta puede contener tanto código como Ether, lo que le permite ejecutar transacciones y funciones de contratos inteligentes. Esto elimina la necesidad de un EOA separado para gestionar las transacciones, permitiendo que los contratos manejen los fondos directamente. + +Etherspot Prime, un SDK de código abierto, simplifica la implementación de la Abstracción de Cuenta para desarrolladores de dApps. Usando un monedero inteligente Etherspot, los usuarios pueden disfrutar de una experiencia web2 a través de logins sociales o transacciones por lotes. + +## Primeros pasos + +Para explorar Account Abstraction con Etherspot, sigue estos pasos: + +### Utilizar una rama diferente: + +1. Clona el repositorio del kit de inicio de Wagmi: + +```sh +git clone https://github.com/wagmi-dev/wagmi-starter-kit.git +``` + +2. Navegue hasta el directorio del proyecto: + +```javascript +cd wagmi-starter-kit +``` + +3. En lugar de utilizar la rama principal, cambie a la rama que contiene las funcionalidades de Abstracción de Cuentas: + +```javascript +git checkout aa-sdk +``` + +4. Ejecuta el proyecto: + Ahora que has clonado el repositorio e instalado las dependencias, es el momento de ejecutar el proyecto. Ejecuta el siguiente comando: + +```javascript +desarrollo del hilo +``` + +Esto iniciará su dApp Rootstock Wagmi localmente, permitiéndole desarrollar y probar sus contratos inteligentes. Puede acceder al servidor Vite en `http://localhost:5173.` + +## Interactuar con la abstracción Cuenta + + + +1. **Generar una cuenta aleatoria:** + +- Haga clic en el botón "Generar" para crear una cuenta aleatoria. + +2. **Generar una dirección de pago:** + +- Pulse el botón "Generar" para obtener una dirección de pago. + +3. **Comprobar saldo de cuenta:** + +- Al hacer clic en Obtener saldo se mostrará el saldo de la dirección de pago. + +4. **Estimar y enviar una transacción:** + +- Esta sección tiene dos campos: + - **Dirección del destinatario:** En este campo se especifica la dirección Ethereum del destinatario. Es la dirección a la que desea enviar la transacción. Piense en ella como el destino de sus fondos. Asegúrese de introducir aquí una dirección Ethereum válida. + + - **Valor (en Eth):** En este campo, usted indica la cantidad de Ether (ETH) que desea enviar en la transacción. Introduzca el valor que desea transferir. Por ejemplo, si desea enviar 0,5 ETH, introduzca "0,5" en este campo. + + - Pulse el botón "Estimar y enviar" para iniciar la transacción. + +## Comprender el código base + +Este código define un componente React llamado Demo, que proporciona una interfaz de usuario para interactuar con las funcionalidades de blockchain a través del SDK de Etherspot. + +El componente permite a los usuarios generar una cuenta de propiedad externa (EOA) aleatoria, generar un monedero Etherspot, comprobar el saldo del monedero Etherspot, y estimar y enviar transacciones utilizando el Arka Paymaster. + +El componente gestiona varios estados e interacciones, lo que facilita la gestión de carteras y la realización de transacciones de blockchain sin tener que tratar directamente con claves privadas. + +1. **generateRandomEOA** + +- Esta función genera una cuenta de propiedad externa (EOA) aleatoria. + +- **Función:** + +Esto genera de forma asíncrona una clave privada y deriva una dirección de cuenta a partir de ella, estableciendo las variables de estado de la dirección del monedero EOA y la clave privada. + +2. **getBalance** + +- Esta función obtiene el saldo del monedero Etherspot actual. + +- **Función:** + Esto utiliza de forma asíncrona el SDK para recuperar el saldo nativo de la cuenta y actualiza la variable de estado de saldo. + +3. **generateEtherspotWallet** + +- Esta función genera una dirección contrafactual para el monedero Etherspot. + +- **Función:** + Esto interactúa de forma asíncrona con el SDK para generar una dirección de cartera Etherspot y obtiene su saldo. + +4. \*\*Estimación y transferencia. + +- Esta función calcula el coste de la transacción y envía un valor especificado a un destinatario utilizando el Arka Paymaster. + +- **Función:** + Valida la dirección del destinatario y las entradas de valor. + Utiliza el SDK para configurar la transacción, estimar el coste del gas, enviar la transacción, y espera el recibo de la transacción. + +5. **useEffect Hook** + +- Este hook inicializa el SDK Prime cuando se establece la clave privada EOA. + +\*\*Parámetros + +**eoaPrivateKey:** La clave privada de la cuenta de propiedad externa (EOA). + +- **Función:** + +**useEffect:** +Configura la instancia de Prime SDK con la eoaPrivateKey. +Configura el SDK con el proveedor de bundler especificado. + +## Recursos + +- [Kit de iniciación a la abstracción de cuentas del patrón](https://github.com/wagmi-dev/wagmi-starter-kit.git) +- [Uso de ejemplos del SDK de Prime](https://etherspot.fyi/prime-sdk/examples/intro) +- [Etherspot Prime SDK Repo](https://github.com/etherspot/etherspot-prime-sdk/) diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/wagmi.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/wagmi.md new file mode 100644 index 00000000..4efc2a1b --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/wagmi.md @@ -0,0 +1,307 @@ +--- +sidebar_label: Uso de Wagmi y React Hooks +sidebar_position: 300 +title: Portainjertos Wagmi Starter dApp +description: El Rootstock Wagmi Starter Kit proporciona una base sólida para el desarrollo de aplicaciones descentralizadas (dApps) en la blockchain Rootstock. Agiliza el desarrollo aprovechando las bibliotecas React, Wagmi y Shadcn. +tags: + - rsk + - portainjertos + - desarrolladores + - wagmi + - inicio rápido + - dApps + - Contratos inteligentes +--- + +El kit de inicio Rootstock Wagmi proporciona una base para la creación de aplicaciones descentralizadas (dApps) en la blockchain Rootstock. +Aprovecha la seguridad de Bitcoin y la flexibilidad de Ethereum. + +El kit utiliza [Wagmi](https://wagmi.sh/), una biblioteca React Hooks, para simplificar los contratos inteligentes y las interacciones de la red blockchain y y [Shadcn libraries](https://ui.shadcn.com/). + +> Este kit de inicio está diseñado para ayudar a los desarrolladores a iniciar su viaje de desarrollo de dApp en Rootstock. + +## Requisitos previos + +- **Node.js y Git:** Asegúrese de tener Node.js y Git instalados en su sistema. + - Consulte la sección [Prerrequisitos](/developers/requirements/#installing-nodejs-and-npm) para saber cómo descargar Node.js usando NVM. +- **Yarn:** Instala Yarn, un gestor de paquetes para proyectos Node.js. Puedes hacerlo ejecutando el siguiente comando en tu terminal: + ```bash + npm install -g yarn + ``` +- \*\*Conocimientos básicos + - [React](https://react.dev/) (biblioteca JavaScript para crear interfaces de usuario) + - [Solidity](https://soliditylang.org/) (un lenguaje de programación para contratos inteligentes Ethereum). + +:::tip[Rootstock Curso para desarrolladores de Blockchain]. + +Aprenda a escribir, probar, asegurar, desplegar y verificar contratos inteligentes en la red blockchain de Rootstock. Inscríbase en el [Rootstock Blockchain Developer Course](/resources/courses/). +::: + +## Configurar + +### 1. Clonar el repositorio + +En primer lugar, tendrá que clonar el repositorio Rootstock Wagmi Starter Kit. Abre tu terminal y ejecuta los siguientes comandos: + +```bash +git clone https://github.com/rsksmart/rsk-wagmi-starter-kit +cd rsk-wagmi-starter-kit +``` + +### 2. Obtener ID de proyecto + +Cada dApp que depende de WalletConnect ahora necesita obtener un projectId de [WalletConnect Cloud](https://cloud.walletconnect.com/). Esto es gratis y solo lleva unos minutos. + +Para conseguir la llave: + +1. Vaya a [Walletconnect](https://cloud.walletconnect.com/sign-up) y regístrese. +2. Cree un nuevo proyecto haciendo clic en **Crear proyecto**. +3. Añade un Nombre y un Enlace a tu proyecto, selecciona un producto (AppKit o WalletKit), selecciona **WalletKit**. +4. Ahora verás el ID del proyecto, cópialo. + +### 3) Configuración del entorno + +Para configurar tu entorno, sigue estos pasos: + +1. Crea un archivo `.env` y añade variables de entorno. + ```text + VITE_WC_PROJECT_ID=Su projectid de la nube Walletconnect + ``` + +### 4) Instalar dependencias + +Antes de ejecutar el proyecto, asegúrate de tener instaladas las dependencias necesarias. Recomendamos utilizar el gestor de paquetes yarn debido a posibles conflictos con los paquetes npm. Ejecute el siguiente comando para instalar las dependencias: + +```bash +hilo +``` + +### 5. Ejecutar el proyecto + +Ahora que has clonado el repositorio e instalado las dependencias, es el momento de ejecutar el proyecto. Ejecute el siguiente comando: + +```bash +desarrollo del hilo +``` + +Esto iniciará la dApp Rootstock Wagmi Starter localmente, permitiéndole desarrollar y probar sus contratos inteligentes. Puedes acceder al servidor Vite en [http://localhost:5173](http://localhost:5173). + +## Resultado + + + +:::info\[Info] + +Después de ejecutar con éxito su proyecto utilizando el comando anterior, haga lo siguiente: + +- Haga clic en el botón "Conectar cartera" para conectarse. Una vez conectado, podrás: +- \*\*Conmuta fácilmente entre Mainnet y Testnet. +- **Ver y copiar su dirección:** Acceda a la dirección de su monedero. +- **Consulta tu saldo de tRBTC:** Consulta tu saldo de tRBTC. +- **Desconectar:** Salir del proyecto. + +::: + +## Proyecto de prueba + +Para probar el proyecto Wagmi, sigue estos sencillos pasos: + +1. **Conecte su cartera:** Haga clic en el botón "Conectar cartera". +2. **Navegue hasta la sección Wagmi:** Desplácese hacia abajo y encuentre la tarjeta etiquetada como "Interacción contractual con el kit de inicio Wagmi". Haga clic en ella. +3. **Explore las pestañas:** En la sección Wagmi, verá tres pestañas: ERC-20, ERC-721 y ERC-1155. Haz clic en cualquiera de estas pestañas para explorar más a fondo. + + + +Proporcionar una sección en el documento acerca de cómo los contratos se llaman en el código, la estructura de carpetas para facilitar la búsqueda de códigos y las principales características de Wagmi y Rainbowkit utilizados en la base de código. + +## Entender el código base + +### Estructura de carpetas + +``` +Público +Src +.env +.env.ejemplo +``` + +La carpeta `src` está organizada para agilizar el proceso de desarrollo y facilitar la localización de código o recursos específicos. Aquí tienes un desglose detallado: + +#### Estructura de la carpeta \`.src + +- **Activos:** Contiene las ABI (Application Binary Interfaces) para ERC20, ERC721 y ERC1155. +- \*\*Componentes + - **AccountAbstraction:** Contiene código relacionado con la abstracción de cuentas. + - **Inicio:** Contiene componentes específicos de la página de inicio. + - **Iconos:** Contiene varios componentes de iconos. + - **Tokens:** Incluye componentes para diferentes tipos de tokens. + - \*\*Interfaz de usuario: Componentes generales de interfaz de usuario utilizados en la aplicación. + - **Pie de página.tsx:** Componente del pie de página. + - \*\*Componente de la barra de navegación. +- **Config:** + - **provider.tsx:** Configuración para proveedores. + - **rainbowkitConfig.ts:** Configuración para RainbowKit. + - **wagmiProviderConfig.ts:** Configuración para proveedores WAGMI. +- **Lib:** Contiene varias carpetas de utilidades para facilitar la organización: + - **Constantes:** Constantes de aplicación. + - **Funciones:** Funciones generales utilizadas en toda la aplicación. + - **Tipos:** Definiciones de tipos. + - **Utilidades:** Funciones de utilidad. +- **Páginas:** + - **index.ts:** Punto de entrada principal. + - **Etherspot.tsx:** Componente de página para Etherspot. + - **Home.tsx:** Componente de la página de inicio. + - **Wagmi.tsx:** Componente de página relacionado con Wagmi. + +### Código para las fichas ERC20, ERC721 y ERC1155 + +El código responsable de las pestañas correspondientes a ERC20, ERC721 y ERC1155 se encuentra en la carpeta de componentes: + +- **ERC20:** Ubicado en el directorio `components/tokens/ERC20`. +- **ERC721:** Ubicado en el directorio `components/tokens/ERC721`. +- **ERC1155:** Ubicado en el directorio `components/tokens/ERC1155`. + +Este enfoque estructurado garantiza la agrupación lógica del código y los activos, lo que facilita la navegación y el mantenimiento. + +#### Comprender el código de ficha ERC20 + +El código interactúa con un contrato inteligente para acuñar tokens tRSK. Aquí tienes un desglose detallado de cómo se consigue: + +1. \*\*Referencia del contrato inteligente + +- **Dirección:** La dirección del contrato inteligente se especifica mediante la constante `ERC20_ADDRESS`. +- **ABI:** La ABI (Application Binary Interface) del contrato, que define las funciones del contrato y sus parámetros, es proporcionada por la constante `abi`. + +2. **Lectura de datos contractuales:** + +```javascript +const { data, isLoading, isError, refetch } = useReadContract({ + abi, + address: ERC20_ADDRESS, + functionName: "balanceOf", + args: [address], +}); +``` + +3. **Escribir en el contrato:** + El hook `useWriteContract` de la librería wagmi se utiliza para interactuar con las funciones de escritura del contrato (funciones que modifican el estado). + +4. **Acuñación de fichas:** + La función `mintTokens` llama a `writeContractAsync` para acuñar fichas tRSK. + +- Argumentos: + - abi: Define las funciones del contrato y sus parámetros. + - Dirección: La dirección del contrato ERC-20 desplegado. + - functionName: El nombre de la función a llamar, que en este caso es "menta". + - args: Un array que contiene la dirección del monedero del usuario y la cantidad a acuñar (100 en este caso). + +```javascript +const mintTokens = async () => { + setLoading(true); + try { + const txHash = await writeContractAsync({ + abi, + address: ERC20_ADDRESS, + functionName: "mint", + args: [address, 100], + }); + await waitForTransactionReceipt(rainbowkitConfig, { + confirmations: 1, + hash: txHash, + }); + setLoading(false); + toast({ + title: "Fichas tRSK acuñadas con éxito", + description: "Actualiza la página para ver los cambios", + }); + refetch(); + } catch (e) { + toast({ + title: "Error", + description: "Failed tot tokens tRSK", + variant: "destructive", + }); + setLoading(false); + console.error(e); + } +}; + +``` + +Esto envía una transacción a la cadena de bloques para ejecutar la función "acuñar" en el contrato inteligente, acuñando así tokens tRSK y depositándolos en la cartera del usuario. + +## Comprender el código de ficha ERC721 + +Este código define un componente React llamado `ERC721Tab`, que proporciona una interfaz de usuario para interactuar con un contrato inteligente ERC-721. + +Las funciones clave dentro de este componente: + +1. UsarReadContract\`: + Este hook se utiliza para leer datos del contrato ERC-721. Obtiene el saldo de NFT de la dirección del usuario conectado. + +- \*\*Parámetros: + - `abi`: La ABI (Application Binary Interface) del contrato ERC-721. + - Dirección La dirección del contrato ERC-721. + - `functionName`: El nombre de la función a llamar en el contrato (balanceOf). + - `args`: Los argumentos a pasar a la función del contrato ([dirección]). + +2. usarWriteContract\`: + Este hook se utiliza para escribir datos en el contrato ERC-721, concretamente para acuñar un nuevo NFT. + +**Función**: + +- WriteContractAsync`: Escribe de forma asíncrona en el contrato llamando a la función `safeMint\` del contrato ERC-721. + +3. mintNFT\`: + Se trata de una función asíncrona que gestiona el proceso de acuñación de un nuevo NFT. + +- \*\*Pasos: + - Establece el estado de carga en true. + - Intenta llamar a la función `safeMint` en el contrato ERC-721 utilizando `writeContractAsync`. + - Espera a que se confirme la transacción mediante `waitForTransactionReceipt`. + - Muestra un mensaje de brindis de éxito si la acuñación se realiza correctamente. + - Obtiene el saldo NFT del usuario llamando a `refetch`. + - Captura cualquier error, lo registra y muestra un mensaje de brindis por el error. + - Establece el estado de carga en false. + +4. Refetch + Esta función forma parte del hook `useReadContract` y se utiliza para refrescar el saldo de NFTs después de una operación de acuñación exitosa. + +5. `toast`: + Esta función se utiliza para mostrar notificaciones tostadas para mensajes de éxito o error. + +El resto del componente contiene JSX para representar los elementos de la interfaz de usuario, incluido un botón para acuñar el NFT, una pantalla de saldo y un enlace para ver los NFT acuñados en un explorador de bloques. + +## Comprender el código de ficha ERC1155 + +El código proporcionado es un componente React que interactúa con un contrato inteligente utilizando el estándar ERC-1155. Permite a los usuarios acuñar tokens y comprobar sus saldos. + +Las funciones clave dentro de este componente: + +1. `ERC1155Tab` Componente: + +**Variables de Estado**: + +- `loading`: Booleano para gestionar el estado de carga durante el minado de tokens. +- Valor Número para almacenar el tipo de token seleccionado para la acuñación. +- Dirección La dirección del monedero del usuario obtenida del hook `useAccount`. + +2. Ganchos `useReadContract`: + Estos ganchos se utilizan para leer datos del contrato inteligente. + +- `useReadContract` para comprobar el saldo de fichas de tipo A (con ID 1). +- `useReadContract` para comprobar el saldo de fichas de tipo B (con ID 2). + +3. Función `mintTokens`: + Función asíncrona que gestiona la acuñación de fichas. + +- \*\*Pasos: + - Llama a `writeContractAsync` para interactuar con el contrato inteligente y acuñar tokens. + - Espera el recibo de la transacción utilizando `waitForTransactionReceipt`. + - Muestra brindis de éxito o error en función del resultado. + - Restablece los datos de la balanza después de la acuñación. + +## Únete a la Comunidad + +Crear dApps puede ser un reto, pero no estás solo. +Únete a la comunidad [Rootstock Discord](http://discord.gg/rootstock) para obtener ayuda, hacer preguntas y colaborar. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/web3-python.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/web3-python.md new file mode 100644 index 00000000..d0894a98 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/04-quickstart/web3-python.md @@ -0,0 +1,632 @@ +--- +sidebar_label: Uso de Web3.py +sidebar_position: 200 +title: Despliegue e interacción con un contrato inteligente utilizando Web3.py +description: Despliegue e Interacción con un Contrato Inteligente Usando Web3.py. +tags: + - inicios rápidos + - rsk + - portainjertos + - ethereum + - python + - web3.py + - desarrolladores + - contratos inteligentes +--- + +[Web3.py](https://web3py.readthedocs.io/en/stable/) es una biblioteca Python que permite a los desarrolladores interactuar con blockchains basadas en Ethereum con Python. Rootstock dispone de una API similar a Ethereum que es totalmente compatible con las invocaciones JSON-RPC al estilo de Ethereum. Por lo tanto, los desarrolladores pueden aprovechar esta compatibilidad y utilizar la biblioteca `Web3.py` para interactuar con Rootstock de forma similar a como los desarrolladores interactúan con los contratos inteligentes en Ethereum. + +En esta guía, usted aprenderá cómo utilizar la biblioteca Web3.py para implementar e interactuar con los contratos inteligentes en Rootstock. + +:::tip[Interact con portainjertos utilizando óxido]. +Consulte el tutorial sobre cómo [interactuar con Rootstock utilizando Rust](/resources/tutorials/rootstock-rust/) +::: + +## Requisitos previos + +- Una cuenta testnet con fondos del tRBTC. + - [Obtener tRBTC](https://faucet.rootstock.io/). +- Una CLAVE API del [Servicio RPC de Rootstock](https://rpc.rootstock.io/). +- Poner en marcha el proyecto +- Un compilador Solidity instalado -> ver [instrucciones de instalación del compilador solidity](https://docs.soliditylang.org/en/latest/installing-solidity.html) + +Configure el proyecto e instale las dependencias: + +```bash +# crear un directorio para el proyecto +mkdir web3-python-guide && cd web3-python-guide + +# instalar python 3.10 +brew install python@3.10 + +# configurar el entorno virtual de desarrollo +python3.10 -m venv env +source env/bin/activate + +# instalar dependencias +pip install Web3 py-solc-x +``` + +Instrucciones de instalación del compilador Solidity para MacOs: + +```bash +brew install solc-select +solc-select use 0.8.19 --always-install + +solc --version +# Versión: 0.8.19+commit.7dd6d404.Darwin.appleclang +``` + +### Establecer secretos para el proyecto + +Estaremos usando datos sensibles que no tienen que ser almacenados en el código, y en su lugar los almacenaremos en un archivo `.env`. + +Para ello, primero vamos a instalar el paquete para leer los datos del archivo `.env`: + +```python +pip install python-dotenv +``` + +A continuación, crearemos un archivo `.env` y añadiremos los secretos: + +```bash +tocar .env +``` + +añada las siguientes variables al archivo: + +Sustituya `YOUR_APIKEY` por la clave API de su panel de control. + +```bash +# obtenga esta YOUR_APIKEY del servicio RPC de Rootstock. +RPC_PROVIDER_APIKEY = '{YOUR_APIKEY}' + +# esta es la clave privada de la cuenta desde la que desplegará el contrato +ACCOUNT_PRIVATE_KEY = '{YOUR_PRIVATE_KEY}' +``` + +## Despliegue de un contrato inteligente + +### Escribir el contrato inteligente + +El contrato que se compilará y desplegará en la siguiente sección es un contrato simple que almacena un mensaje, y permitirá establecer diferentes mensajes enviando una transacción. + +Puede empezar creando un expediente para el contrato: + +```bash +toque Greeter.sol +``` + +A continuación, añada el código Solidity al archivo: + +```s +// SPDX-Licencia-Identificador: MIT + +pragma solidity >0.5.0; + +contract Greeter { + string public greeting; + + constructor() public { + greeting = 'Hola'; + } + + function setGreeting(string memory _greeting) public { + greeting = _greeting; + } + + function greet() view public returns (string memory) { + return greeting; + } +} +``` + +La función constructora, que se ejecuta cuando se despliega el contrato, establece el valor inicial de la variable de cadena almacenada en la cadena en "Hola". La función setGreeting añade el `_greeting` proporcionado al saludo, pero es necesario enviar una transacción, que modifica los datos almacenados. Por último, la función `greet` recupera el valor almacenado. + +### Compilar el contrato inteligente + +Crearemos un script que utilice el compilador Solidity para generar el código de bytes y la interfaz (ABI) del contrato `Greeter.sol`. Para empezar, crearemos un archivo `compile.py` ejecutando: + +```bash +toca compilar.py +``` + +A continuación, crearemos el script para este archivo y completaremos los siguientes pasos: +Importar el paquete `solcx`, que compilará el código fuente +Compilar el contrato `Greeter.sol` utilizando la función `solcx.compile_files` +Exportar la ABI y el bytecode del contrato. + +Codifica y pega el código de abajo en `compile.py`; + +```s +import solcx +solcx.install_solc('0.8.19') + +# Compilar contrato +temp_file = solcx.compile_files( + 'Greeter.sol', + output_values=['abi', 'bin'], + solc_version='0.8.19' +) + +# Exportar datos del contrato +abi = temp_file['Greeter.sol:Greeter']['abi'] +bytecode = temp_file['Greeter.sol:Greeter']['bin'] +``` + +Ahora puede ejecutar el script para compilar el contrato: + +```python +python compilar.py +``` + +### Despliegue del contrato inteligente + +Con el script para compilar el contrato `Greeter.sol` en su sitio, puedes usar los resultados para enviar una transacción firmada que lo despliegue. Para ello, puedes crear un archivo para el script de despliegue llamado `deploy.py`: + +```bash +tocar deploy.py +``` + +A continuación, creará el script para este archivo y completará los siguientes pasos: + +1. Añadir importaciones, incluyendo `Web3.py` y el ABI y bytecode del contrato `Greeter.sol`. +2. Configurar el proveedor Web3 + +Para configurar el Proveedor Web3, tenemos que leer las variables de entorno que hemos añadido previamente al archivo .env. + +```text +# Añade el proveedor Web3 +RPC_PROVIDER_APIKEY = os.getenv('RPC_PROVIDER_APIKEY') +RPC_PROVIDER_URL = 'https://rpc.testnet.rootstock.io/' + RPC_PROVIDER_APIKEY +web3 = Web3(Web3.HTTPProvider(RPC_PROVIDER_URL)) +``` + +3. Defina la `cuenta_de`. La clave privada es necesaria para firmar la transacción. Nota: Esto es sólo para propósitos de ejemplo. Nunca almacene sus claves privadas en su código + +```text +# Establece la cuenta por defecto +PRIVATE_KEY = os.getenv('ACCOUNT_PRIVATE_KEY') +account_from = { + 'private_key': PRIVATE_KEY, + 'address': web3.eth.account.from_key(PRIVATE_KEY).address +} +``` + +4. Crear una instancia de contrato utilizando la función `web3.eth.contract` y pasando la ABI y el bytecode del contrato. +5. Establece la [estrategia de precio del gas](https://web3py.readthedocs.io/en/stable/gas_price.html#gas-price) usando la función `web3.eth.set_gas_price_strategy`, que nos permitirá obtener el precio del gas del proveedor RPC. Esto es importante porque, de lo contrario, la biblioteca Web3 intentará utilizar los métodos RPC `eth_maxPriorityFeePerGas` y `eth_feeHistory`, que sólo son compatibles con los nodos Ethereum posteriores a Londres. +6. Construye un constructor de transacción utilizando la instancia del contrato. Entonces usarás la función `build_transaction` para pasar la información de la transacción incluyendo la dirección `from` y el `nonce` para el remitente. Para obtener el `nonce` puedes usar la función \`web3.eth.get_transaction_count +7. Firmar la transacción utilizando la función `web3.eth.account.sign_transaction` y pasar en el constructor transacción y la `private_key` del remitente. +8. Utilizando la transacción firmada, puede enviarla utilizando la función `web3.eth.send_raw_transaction` y esperar la recepción de la transacción utilizando la función `web3.eth.wait_for_transaction_receipt`. + +Codifica y pega el código de abajo en `deploy.py`; + +```bash +from compile import abi, bytecode +from web3 import Web3 +from web3.gas_strategies.rpc import rpc_gas_price_strategy +from dotenv import load_dotenv +import os + +load_dotenv() + +# Añade el proveedor Web3 +RPC_PROVIDER_APIKEY = os.getenv('RPC_PROVIDER_APIKEY') +RPC_PROVIDER_URL = 'https://rpc.testnet.rootstock.io/' + RPC_PROVIDER_APIKEY +web3 = Web3(Web3.HTTPProvider(RPC_PROVIDER_URL)) + + +# Establecer la cuenta por defecto +PRIVATE_KEY = os.getenv('ACCOUNT_PRIVATE_KEY') +account_from = { + 'private_key': PRIVATE_KEY, + 'address': web3.eth.account.from_key(PRIVATE_KEY).address +} + +print("Attempting to deploy from account: ", account_from['address']) + +# Create contract instance +Greeter = web3.eth.contract(abi=abi, bytecode=bytecode) + +# Set the gas price strategy +web3.eth.set_gas_price_strategy(rpc_gas_price_strategy) + +# Construir la transacción +construct_txn = Greeter.constructor().build_transaction({ + 'from': account_from['address'], + 'nonce': web3.eth.get_transaction_count(account_from['address']), + 'gasPrice': web3.eth.generate_gas_price() +}) + +# Firmar la transacción que despliega el contrato +signed_txn = web3.eth.account.sign_transaction(construct_txn, account_from['private_key']) + +# Enviar la transacción que despliega el contrato +txn_hash = web3.eth.send_raw_transaction(signed_txn.rawTransaction) + +# Esperar a que se realice la transacción y obtener el recibo de la transacción +txn_receipt = web3.eth.wait_for_transaction_receipt(txn_hash) +print(f "Transacción realizada correctamente con hash: { txn_receipt.transactionHash.hex() }") +print(f "Contrato desplegado en la dirección: { txn_receipt.contractAddress }") +``` + +Ahora puede ejecutar el script y obtener el resultado. + +```python +python deploy.py + +>> Intentando desplegar desde cuenta: 0x3b32a6463Bd0837fBF428bbC2A4c8B4c022e5077 +>> Transacción exitosa con hash: 0x98a256c106bdb65e4de6a267e94000acdfe0d6f23c3dc1444f14dccf00713a69 +>> Contrato desplegado en la dirección: 0xba39f329255d55a0276c695111b2edc9250C2341 +``` + +Nota: Guarde la dirección del contrato, ya que la utilizaremos más adelante en la guía. + +## Interactuar con un contrato inteligente + +### Lectura de datos contractuales (métodos de llamada) + +Los métodos de llamada son el tipo de interacción que no modifica el almacenamiento del contrato (variables de cambio), lo que significa que no es necesario enviar ninguna transacción. Simplemente leen varias variables de almacenamiento del contrato desplegado. + +Para empezar, puedes crear un archivo y llamarlo `getMessage.py`: + +```text +tocar getMessage.py +``` + +A continuación, puede seguir los siguientes pasos para crear el script: + +1. Añade importaciones, incluyendo `Web3.py` y la ABI del contrato `Greeter.sol`. +2. Configure el proveedor Web3 y sustituya YOUR_APIKEY +3. De fine the `contract_address` of the deployed contract +4. Crear una instancia de contrato utilizando la función `web3.eth.contract` y pasando el ABI y la dirección del contrato desplegado. +5. Utilizando la instancia del contrato, puede llamar a la función \`greet + +Codifica y pega el código de abajo en `getMessage.py`; + +```bash +from compile import abi +from web3 import Web3 +from dotenv import load_dotenv +import os + +load_dotenv() + +# Añade el proveedor Web3 +RPC_PROVIDER_APIKEY = os.getenv('RPC_PROVIDER_APIKEY') +RPC_PROVIDER_URL = 'https://rpc.testnet.rootstock.io/' + RPC_PROVIDER_APIKEY +web3 = Web3(Web3.HTTPProvider(RPC_PROVIDER_URL)) + + +# Crear variable de dirección (utiliza la dirección del contrato que acabas de desplegar) +contract_address = '0xba39f329255d55a0276c695111b2edc9250C2341' + +print(f "Haciendo una llamada al contrato en la dirección: { contract_address }") + +# Crear instancia de contrato +Greeter = web3.eth.contract(address=dirección_contrato, abi=abi) + +# Llamar al contrato +call_result = Greeter.functions.greet().call() +print(f "Contrato devuelto: { call_result }") +``` + +Si tiene éxito, la respuesta se mostrará en el terminal: + +```python +python getMessage.py + +>> Realizando una llamada a contrato en la dirección: 0xba39f329255d55a0276c695111b2edc9250C2341 +>> Contrato devuelto: Hola +``` + +### Escribir datos en el contrato (métodos de escritura) + +Los métodos de escritura son el tipo de interacción que modifica el almacenamiento del contrato (variables de cambio), lo que significa que es necesario firmar y enviar una transacción. En esta sección, crearás el script para cambiar el texto almacenado en el contrato Greeter. + +Para empezar, puedes crear un archivo para el script y llamarlo `setMessage.py`: + +```bash +tocar setMessage.py +``` + +Abre el archivo `setMessage.py` y sigue los siguientes pasos para crear el script: + +1. Añade importaciones, incluyendo Web3.py y la ABI del contrato Incrementer.sol +2. Configurar el proveedor Web3 +3. Define la variable `account_from`, incluyendo la `private_key`, y la `contract_address` del contrato desplegado. La clave privada es necesaria para firmar la transacción. Nota: Esto es sólo a modo de ejemplo. Nunca almacene sus claves privadas en su código +4. Crear una instancia de contrato utilizando la función `web3.eth.contract` y pasando el ABI y la dirección del contrato desplegado. +5. Establece la estrategia del precio del gas usando la función `web3.eth.set_gas_price_strategy`, que nos permitirá obtener el precio del gas del proveedor RPC. Esto es importante porque, de lo contrario, la biblioteca Web3 intentará utilizar los métodos RPC `eth_maxPriorityFeePerGas` y `eth_feeHistory`, que sólo son compatibles con los nodos Ethereum posteriores a Londres. +6. Construye la transacción `setGreeting` usando la instancia del contrato y pasando el nuevo mensaje. Luego usarás la función `build_transaction` para pasar la información de la transacción incluyendo la dirección `from` y el `nonce` del remitente. Para obtener el `nonce` puedes usar la función \`web3.eth.get_transaction_count +7. Firma la transacción usando la función `web3.eth.account.sign_transaction` y pasa la transacción `setGreeting` y la `private_key` del remitente. +8. Utilizando la transacción firmada, puedes enviarla utilizando la función `web3.eth.send_raw_transaction` y esperar la recepción de la transacción utilizando la función `web3.eth.wait_for_transaction_receipt`. + +Codifica y pega el código de abajo en `setMessage.py`; + +```bash +from compile import abi +from web3 import Web3 +from web3.gas_strategies.rpc import rpc_gas_price_strategy +from dotenv import load_dotenv +import os + +load_dotenv() + +# Añade el proveedor Web3 +RPC_PROVIDER_APIKEY = os.getenv('RPC_PROVIDER_APIKEY') +RPC_PROVIDER_URL = 'https://rpc.testnet.rootstock.io/' + RPC_PROVIDER_APIKEY +web3 = Web3(Web3.HTTPProvider(RPC_PROVIDER_URL)) + + +# Establecer la cuenta por defecto +PRIVATE_KEY = os.getenv('ACCOUNT_PRIVATE_KEY') +account_from = { + 'private_key': PRIVATE_KEY, + 'address': web3.eth.account.from_key(PRIVATE_KEY).address +} + +# Crear variable de dirección +contract_address = '0xba39f329255d55a0276c695111b2edc9250C2341' + +# Crear instancia de contrato +Greeter = web3.eth.contract(address=contract_address, abi=abi) + +# Establecer la estrategia de precio del gas +web3.eth.set_gas_price_strategy(rpc_gas_price_strategy) + +# Crear la transacción +txn = Greeter.functions.setGreeting('¡Hola, mundo!').build_transaction({ + 'from': account_from['address'], + 'nonce': web3.eth.get_transaction_count(account_from['address']), + 'gasPrice': web3.eth.generate_gas_price() +}) + +# Firmar la transacción +signed_txn = web3.eth.account.sign_transaction(txn, account_from['private_key']) + +# Enviar la transacción +txn_hash = web3.eth.send_raw_transaction(signed_txn.rawTransaction) +txn_receipt = web3.eth.wait_for_transaction_receipt(txn_hash) + +print(f "Transacción correcta con hash: { txn_receipt.transactionHash.hex() }") +``` + +Si tiene éxito, el hash de la transacción se mostrará en el terminal. + +```python +python setMessage.py + +>> Transacción exitosa con hash: 0x95ba4e13269aba8e51c3037270c0ee90f4872c36e076fc94e51226c1597f6d86 +``` + +Ahora puedes ejecutar el script `getMessage.py` para obtener el nuevo valor almacenado en el contrato. + +```python +python getMessage.py + +>> Realizando una llamada a contrato en la dirección: 0xba39f329255d55a0276c695111b2edc9250C2341 +>> Contrato devuelto: ¡Hola, Mundo! +``` + +## Envío de transacciones + +Aquí entenderá cómo comprobar el saldo de una cuenta y cómo enviar `tRBTC` de una cuenta a otra. + +### Consultar el saldo de una cuenta + +Aquí crearás un script que comprueba el saldo de una cuenta. +En primer lugar, comience por crear un archivo para el script. + +```python +tocar balances.py +``` + +A continuación, creará el script para este archivo y completará los siguientes pasos: + +1. Configurar el proveedor Web3 +2. Definir las variables `dirección_de` y \`dirección_a +3. Obtener el saldo de las cuentas utilizando la función `web3.eth.get_balance` y formatear los 3. resultados utilizando la función `web3.from_wei`. + +Codifica y pega el código de abajo en `balances.py`; + +```bash +from web3 import Web3 +from dotenv import load_dotenv +import os + +load_dotenv() + + +# Añade el proveedor Web3 +RPC_PROVIDER_APIKEY = os.getenv('RPC_PROVIDER_APIKEY') +RPC_PROVIDER_URL = 'https://rpc.testnet.rootstock.io/' + RPC_PROVIDER_APIKEY +web3 = Web3(Web3.HTTPProvider(RPC_PROVIDER_URL)) + + +# Crear variables de dirección +address_from = '0x3b32a6463Bd0837fBF428bbC2A4c8B4c022e5077' +address_to = '0xcff73226883c1cE8b3bcCc28E45c3c92C843485c' + +# Obtener el saldo del remitente +balance_from = web3.from_wei(web3.eth.get_balance(address_from), 'ether') +print(f "Saldo de la dirección del remitente {address_from}: { balance_from } TRBTC") + +# Obtener el saldo del receptor +balance_to = web3.from_wei(web3.eth.get_balance(address_to), 'ether') +print(f "Saldo de la dirección del receptor {address_to}: { balance_to } TRBTC") +``` + +Ejecuta el script: + +```python +python balances.py + +# >> Saldo de la dirección del remitente 0x3b32a6463Bd0837fB428bbC2A4c8B4c022e5077: 0.192538506119378425 TRBTC +# >> Saldo de la dirección del destinatario 0xcff73226883c1cE8b3bcCc28E45c3c92C843485c: 0.407838671951567233 TRBTC +``` + +### Enviar TRBTC + +Aquí crearás un script para enviar tRBTC de una cuenta a otra. +Primero, empieza por crear un archivo para el script. + +```bash +tocar transaction.py +``` + +A continuación, creará el script para este archivo y completará los siguientes pasos: + +1. Añadir importaciones, incluyendo `Web3.py` y el `rpc_gas_price_strategy`, que se utilizará en los siguientes pasos para obtener el precio del gas utilizado para la transacción. +2. Configurar el proveedor Web3 +3. Defina las variables `account_from`, incluida la `private_key`, y `address_to`. La clave privada es necesaria para firmar la transacción. Nota: Esto es sólo para propósitos de ejemplo. Nunca almacene sus claves privadas en su código +4. Utilice la API de precios del gas `Web3.py` para establecer una estrategia de precios del gas. Para este ejemplo, utilizarás la estrategia importada `rpc_gas_price_strategy`. Esto es importante porque, de lo contrario, la biblioteca Web3 intentará utilizar los métodos RPC `eth_maxPriorityFeePerGas` y `eth_feeHistory`, que sólo son compatibles con los nodos Ethereum posteriores a Londres. +5. Crea y firma la transacción usando la función `web3.eth.account.sign_transaction`. Introduce el `nonce`, `gas`, `gasPrice`, `to`, y el valor de la transacción junto con la `private_key` del remitente. Para obtener el `nonce` puedes utilizar la función `web3.eth.get_transaction_count` y pasar la dirección del remitente. Para predeterminar el `gasPrice` utilizarás la función `web3.eth.generate_gas_price`. Para el valor, puedes formatear la cantidad a enviar de un formato fácilmente legible a Wei utilizando la función `web3.to_wei`. +6. Utilizando la transacción firmada, puedes enviarla utilizando la función `web3.eth.send_raw_transaction` y esperar la recepción de la transacción utilizando la función `web3.eth.wait_for_transaction_receipt`. + +Codifica y pega el código de abajo en `transaction.py`; + +```bash +from web3 import Web3 +from web3.gas_strategies.rpc import rpc_gas_price_strategy +from dotenv import load_dotenv +import os + +load_dotenv() + +# Añade el proveedor Web3 +RPC_PROVIDER_APIKEY = os.getenv('RPC_PROVIDER_APIKEY') +RPC_PROVIDER_URL = 'https://rpc.testnet.rootstock.io/' + RPC_PROVIDER_APIKEY +web3 = Web3(Web3.HTTPProvider(RPC_PROVIDER_URL)) + + + +# Establecer la cuenta por defecto +PRIVATE_KEY = os.getenv('ACCOUNT_PRIVATE_KEY') +account_from = { + 'private_key': PRIVATE_KEY, + 'address': web3.eth.account.from_key(PRIVATE_KEY).address +} +address_to = '0xcff73226883c1cE8b3bcCc28E45c3c92C843485c' + +print(f "Attempting to send transaction from { account_from['address'] } to { address_to }") + +# Set the gas price strategy +web3.eth.set_gas_price_strategy(rpc_gas_price_strategy) + +# Construye la transacción +txn = { + 'to': address_to, + 'value': web3.to_wei(0.0001, 'ether'), + 'gas': 21000, + 'gasPrice': web3.eth.generate_gas_price(), + 'nonce': web3.eth.get_transaction_count(account_from['address']) +} + +# Firmar la transacción +signed_txn = web3.eth.account.sign_transaction(txn, account_from['private_key']) + +# Enviar la transacción +txn_hash = web3.eth.send_raw_transaction(signed_txn.rawTransaction) + +# Esperar a que la transacción se extraiga y obtener el recibo de la transacción +txn_receipt = web3.eth.wait_for_transaction_receipt(txn_hash) +print(f "Transacción correcta con hash: { txn_receipt.transactionHash.hex() }") +``` + +Ejecuta el script: + +```python +python transaction.py + +Intentando enviar transacción de 0x112621448Eb148173d5b00edB14B1f576c58CEE a 0xcff73226883c1cE8b3bcCc28E45c3c92C843485c +Transacción exitosa con hash: 0x79ab8be672b0218d31f81876c34321ee7b08e6a4ec8bfff5249f70c443cbce00 +``` + +## Resumen + +En esta guía, hemos aprendido a utilizar la biblioteca Web3.py para implementar, interactuar con un contrato inteligente y enviar transacciones en Rootstock. + +## Solución de problemas + +````mdx-code-block + + + 1. Mensaje de error: el método eth_sendTransaction no existe + + - Al desplegar un contrato inteligente, o al intentar interactuar con él, puedes recibir el mensaje "method not found": + ```bash + web3.exceptions.MethodUnavailable: {'code': -32601, 'message': 'El método eth_sendTransaction no existe/no está disponible. Ver métodos disponibles en https://dev.rootstock.io/developers/rpc-api/methods'} + ``` + - Nota: La causa del error en el despliegue es que el módulo Web3.py está configurado para utilizar las claves privadas del proveedor RPC (Hosted Keys), que es una forma heredada de utilizar cuentas, y no está soportada por los proveedores RPC modernos, ya que no almacenan claves privadas. + - Métodos como `web3.eth.send_transaction` no funcionan con proveedores RPC, porque se basan en el estado de un nodo y todos los nodos modernos no tienen estado, lo que por debajo hace llamadas JSON-RPC a métodos como `eth_accounts` y `eth_sendTransaction`. Siempre debes usar claves privadas locales cuando trabajes con nodos alojados por otra persona. + - Si no estás familiarizado, ten en cuenta que puedes [exportar tus claves privadas desde Metamask](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key) y otros monederos. Recuerda no compartir nunca tus claves privadas, y no las pongas en tu código o repositorio. + - Para poder desplegar con éxito el contrato, el desarrollador necesita configurar Web3.py para usar sus Claves Privadas Locales, y para construir y pre-firmar la transacción antes de enviarla, por lo que el módulo usa `eth_sendRawTransaction` en su lugar. + - Para permitir que Web3.py use las claves locales, tenemos que usar el middleware de firma para añadir la clave privada al llavero de firma. + ```bash + import os + from eth_account import Account + from eth_account.signers.local import LocalAccount + from web3 import Web3, EthereumTesterProvider + from web3.middleware import construct_sign_and_send_raw_middleware + + w3 = Web3(EthereumTesterProvider()) + + private_key = os.environ.get("PRIVATE_KEY") + assert private_key is not None, "Debe establecer la variable de entorno PRIVATE_KEY" + assert private_key.startswith("0x"), "La clave privada debe comenzar con el prefijo hexadecimal 0x" + + account: LocalAccount = Account.from_key(private_key) + w3.middleware_onion.add(construct_sign_and_send_raw_middleware(account)) + + print(f "La dirección de tu hot wallet es {account.address}") + ``` + - Ahora puedes usar las funciones web3.eth.send_transaction(), Contract.functions.xxx.transact() con tu clave privada local a través del middleware y ya no te aparece el error "ValueError: El método eth_sendTransaction no existe/no está disponible. + + + + 2. Mensaje de error: el método eth_feeHistory o eth_maxPriorityFeePerGas no existe + + - Web3.js intentará utilizar estos métodos porque el fork de Ethereum London introdujo los parámetros de transacción `maxFeePerGas` y `maxPriorityFeePerGas` que pueden utilizarse en lugar de `gasPrice`, que utiliza Rootstock. Por esta razón, tenemos que definir el comportamiento de Web3 para rellenar el precio del gas. Esto se hace usando una "Estrategia de Precio del Gas" - un método que toma el objeto Web3 y un diccionario de transacciones y devuelve un precio del gas (denominado en wei). + - Una estrategia de precio del gas se implementa como un método python con la siguiente firma, y estableciendo la estrategia de precio del gas llamando a [set_gas_price_strategy()](https://web3py.readthedocs.io/en/stable/web3.eth.html#web3.eth.Eth.set_gas_price_strategy). + - Establecer un precio del gas específico: + ```bash + from web3 import Web3, HTTPProvider + + # especificar el precio del gas en wei + GAS_PRICE = 60000000 + + def gas_price_strategy(web3, transaction_params=None): + return GAS_PRICE + + # establecer la estrategia del precio del gas + w3.eth.set_gas_price_strategy(gas_price_strategy) + ``` + - Usando el método `eth_gasPrice`: + - Hace una llamada al [método JSON-RPC eth_gasPrice](https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_gasprice) que devuelve el precio del gas configurado por el nodo Ethereum conectado. + ```bash + from web3.gas_strategies.rpc import rpc_gas_price_strategy + from web3 import Web3, HTTPProvider + + RPC_PROVIDER = 'https://rpc.testnet.rootstock.io/{API_KEY}' + + w3 = Web3(HTTPProvider(RPC_PROVIDER)) + w3.eth.set_gas_price_strategy(rpc_gas_price_strategy) + + gasPrice = w3.eth.generate_gas_price() + + print('gasPrice: ', gasPrice) + ``` + + + +```` + +#### Recursos + +- [Web3.py: Estrategia de precios del gas](https://web3py.readthedocs.io/en/stable/gas_price.html#gas-price) +- [Infura: eth_accounts](https://docs.infura.io/api/networks/ethereum/json-rpc-methods/eth_accounts) +- [Infura: eth_sendTransaction](https://docs.infura.io/api/networks/ethereum/json-rpc-methods/eth_sendtransaction) +- [Web3.py: Trabajo con claves privadas locales](https://web3py.readthedocs.io/en/stable/web3.eth.account.html#working-with-local-private-keys) +- [Web3.py: Ejemplo de despliegue de contratos](https://web3py.readthedocs.io/en/stable/web3.contract.html) +- [Web3.py: Firmar una transacción contractual](https://web3py.readthedocs.io/en/stable/providers.html) +- [Web3.py: Configuración de un proveedor RPC](https://web3py.readthedocs.io/en/stable/providers.html) diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/configure-hardhat-rootstock.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/configure-hardhat-rootstock.md new file mode 100644 index 00000000..9091adcc --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/configure-hardhat-rootstock.md @@ -0,0 +1,89 @@ +--- +sidebar_label: Configurar Hardhat para Rootstock +sidebar_position: 102 +title: Configurar Hardhat para Rootstock +description: Aprenda a configurar su proyecto Hardhat para su desarrollo en la red de pruebas y la red principal de Rootstock. +tags: + - guías + - desarrolladores + - contratos inteligentes + - rsk + - portainjertos + - casco + - dApps + - éteres +--- + +## Requisitos previos + +1. Cuentas/direcciones compatibles con Rootstock. + +- Puede utilizar cuentas existentes o crear cuentas nuevas. Véase [Direcciones basadas en cuentas](/concepts/account-based-addresses/). + +2. Cartera + +- Configure un [monedero Metamask](/dev-tools/wallets/metamask/) y obtenga una [clave privada](/developers/blockchain-essentials/browser#private-keys-and-public-keys). + +## Primeros pasos + +### Paso 1: Configurar el entorno del casco + +- Instale dotenv + Para gestionar las variables de entorno, instale `dotenv` utilizando el siguiente comando: + +```shell + npm install dotenv +``` + +- Crear un archivo \`.env + - En la raíz del proyecto `rootstock-quick-start-guide`, crea un archivo `.env` y añade tus claves privadas (no compartas este archivo): + +```shell + ROOTSTOCK_MAINNET_PRIVATE_KEY="tu_clave_privada_mainnet" + ROOTSTOCK_TESTNET_PRIVATE_KEY="tu_clave_privada_testnet" +``` + +:::info[Note] +Dependiendo de la red que desee, el uso de una clave privada Testnet y Mainnet es opcional, ya que no es necesario que tenga claves privadas separadas en su variable de entorno. +::: + +### Paso 2: Configurar claves privadas + +Para configurar tus claves privadas `rskMainnet` y `rskTestnet`, necesitarás actualizar tu archivo `hardhat.config.js` en el directorio raíz con tus claves privadas. + +- Copie el siguiente fragmento de código y reemplace el código existente en su archivo `hardhat.config.js`. Ver [archivo diff](https://github.com/rsksmart/rootstock-quick-start-guide/blob/d018514628c4888cdba8bcdcf307cc5a2077e496/hardhat.config.js#L1) para el código inicial. + +```js + require("@nomiclabs/hardhat-ethers"); + require('dotenv').config(); + + + module.exports = { + solidity: "0.8.20", + networks: { + rskMainnet: { + url: "https://rpc.mainnet.rootstock.io/{YOUR_APIKEY}", + chainId: 30, + gasPrice: 60000000, + accounts: [process.env.ROOTSTOCK_MAINNET_PRIVATE_KEY] + }, + rskTestnet: { + url: "https://rpc.testnet.rootstock.io/{YOUR_APIKEY}", + chainId: 31, + gasPrice: 60000000, + accounts: [process.env.ROOTSTOCK_TESTNET_PRIVATE_KEY] + } + } + }; +``` + +> Vea cómo [Obtener una clave API de la API RPC](/developers/rpc-api/setup/) + +> Sustituye `"tu_clave_privada_mainnet"` y `"tu_clave_privada_testnet"` por tus claves privadas. Para obtener información sobre cómo recuperar sus claves privadas, consulte [Cómo exportar la clave privada de una cuenta](https://support.metamask.io/hc/en-us/articles/360015289632-How-to-export-an-account-s-private-key). + +### Paso 3: Financiar sus cuentas + +- Mainnet + - Necesitarás RBTC, que puedes obtener de un intercambio. Consulte [Obtener RBTC mediante intercambios](https://rootstock.io/rbtc/). +- Testnet + - Puedes obtener tRBTC en el [Grifo de portainjertos](https://faucet.rootstock.io/). diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/create-hardhat-project.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/create-hardhat-project.md new file mode 100644 index 00000000..814766e9 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/create-hardhat-project.md @@ -0,0 +1,45 @@ +--- +sidebar_label: Crear un proyecto de casco +sidebar_position: 101 +title: Crear un proyecto de casco +description: Aprenda a configurar su entorno de desarrollo con Hardhat +tags: + - guías + - desarrolladores + - contratos inteligentes + - rsk + - portainjertos + - casco + - dApps + - éteres +--- + +En esta sección, aprenderá a crear un proyecto hardhat y a verificar la instalación de hardhat. + +## Clonar el repositorio de proyectos + +Para empezar, clone el repositorio [rootstock-quick-start-guide](https://github.com/rsksmart/rootstock-quick-start-guide.git): + +```shell +git clone https://github.com/rsksmart/rootstock-quick-start-guide.git +``` + +## Instalar dependencias + +Ejecute el siguiente comando en la raíz del proyecto. + +```shell + npm instalar +``` + +> El repositorio de inicio rápido ya viene preinstalado con hardhat. La rama `master` tiene la configuración inicial y el proyecto barebones y la rama `feat/complete` tiene el estado completo del proyecto hardhat. Puedes ver el diff en las ramas de estado inicial y completo del repositorio en cualquier momento mientras revisas este material. Para ejecutar el proyecto completo, haz checkout en la rama feat/complete, instala las dependencias y ejecuta el comando: `npx http-server`. + +### Verificar la instalación del casco + +Aquí verificaremos la instalación del casco en su proyecto. + +- Para verificar la instalación del casco: + - El repositorio [quickstart](https://github.com/rsksmart/rootstock-quick-start-guide) viene con Hardhat preinstalado. Para comprobar si Hardhat está instalado, ejecute `npx hardhat` en el directorio `rootstock-quick-start-guide`. + - `npx hardhat` no sólo verifica la instalación, sino que también le permite iniciar un nuevo proyecto Hardhat si no existe. Para un nuevo proyecto, se le pedirá que elija entre varias opciones. Para crear un proyecto en blanco, selecciona **Create an empty hardhat.config.js**, o elige una de las otras opciones para comenzar con una plantilla preestablecida. + +Una vez finalizada la instalación, puede comprobar que Hardhat se ha instalado correctamente ejecutando de nuevo `npx hardhat`. Debería aparecer un mensaje de ayuda con las tareas disponibles, indicando que Hardhat está instalado y listo para usar. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/deploy-smart-contracts.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/deploy-smart-contracts.md new file mode 100644 index 00000000..1cd578e4 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/deploy-smart-contracts.md @@ -0,0 +1,147 @@ +--- +sidebar_label: Implantar contratos inteligentes +sidebar_position: 105 +title: Implantar contratos inteligentes +description: Aprenda a desplegar su contrato inteligente Rootstock en su entorno local y en la red Rootstock. +tags: + - guías + - desarrolladores + - contratos inteligentes + - rsk + - portainjertos + - casco + - dApps + - éteres +--- + +En esta sección, desplegaremos su contrato de token en su entorno local y también desplegaremos e interactuaremos con el contrato en la red Rootstock. + +## Paso 1: Configurar el archivo de implantación + +Para configurar el archivo de despliegue: + +- Navegue hasta el directorio `scripts` en el directorio raíz del repositorio de inicio rápido: + +```shell + cd guiones +``` + +- En el directorio de scripts, abra el archivo de despliegue `deploy.js`: + +Para desplegar el contrato `myToken`, copie el script de despliegue que aparece a continuación y péguelo en su archivo de despliegue o consulte el archivo [`deploy.js`](https://raw.githubusercontent.com/rsksmart/rootstock-quick-start-guide/feat/complete/scripts/deploy.js) en GitHub. + +```js + async function main() { + const [deployer] = await ethers.getSigners(); + + console.log("Desplegando contratos con la cuenta:", deployer.address); + + const MyToken = await ethers.getContractFactory("MyToken"); + const myToken = await MyToken.deploy(1000); + + console.log("Dirección del token:", myToken.address); + } + + main().catch((error) => { + console.error(error); + process.exitCode = 1; +}); +``` + +## Paso 2: Ejecutar la red Hardhat localmente + +> Nota: Necesitas tener suficientes RBTC en tu cuenta de despliegue para las tasas de gas. Consulte la sección [Financie su cuenta] (/developers/smart-contracts/hardhat/configure-hardhat-rootstock#step-3-fund-your-accounts). + +Para ejecutar la red Hardhat localmente: + +- Iniciar la red Hardhat + - Hardhat viene con una red Ethereum integrada para el desarrollo. Ejecuta el siguiente comando en el directorio raíz de tu proyecto para iniciarlo. + ```shell + nodo casco npx + ``` + Este comando iniciará una red blockchain local y mostrará una lista de cuentas y claves privadas disponibles: + ![Nodo Rootstock en ejecución](/img/guides/quickstart/hardhat/run-node.png) +- Despliegue de su contrato en la red local + - Despliega tu contrato en la red local Hardhat, en otro terminal o símbolo del sistema, ejecuta el siguiente comando en el directorio raíz: + + ```shell + npx hardhat run --network hardhat scripts/deploy.js + ``` + + Esto debería dar un resultado similar al siguiente: + + ```shell + npx hardhat run --network hardhat scripts/deploy.js + + Desplegando contratos con la cuenta: 0xf39Fd6e51aad88F6F4ce6aB88279cffFb92266 + Dirección del token: 0x5FbDB2315678afecb367f032d93F642f64180aa3 + ``` + +## Paso 3: Implemente su contrato en la red Rootstock + +Siga estos pasos para implementar su contrato en la red Rootstock: + +- Utilice el comando de ejecución de Hardhat para desplegar su contrato, dependiendo de la red deseada. Puede elegir desplegar en la Testnet o en la Mainnet de Rootstock. + +Para desplegarlo en la red de pruebas del patrón raíz, ejecute: + +```shell + npx hardhat run --network rskTestnet scripts/deploy.js +``` + +Esto debería devolver lo siguiente: + +```shell +% npx hardhat run --network rskTestnet scripts/deploy.js +Desplegando contratos con la cuenta: 0xA210D04d707f6beBF914Cb1a57199Aebe7B40380 +Dirección del token: 0xc6EcBe0F6643825FD1AAfc03BEC999014759a279 +``` + +- Para desplegar en la red principal de Rootstock, ejecute: + +```shell + npx hardhat run --network rskMainnet scripts/deploy.js +``` + +### Configurar MetaMask + +:::note[Install Metamask] + +::: + +## Paso 4: Conectar Remix a Rootstock Testnet (opcional) + +1. Abrir Remix IDE + + - Vaya a [Remix IDE](https://remix.ethereum.org/) en su navegador. + +2. Conecta MetaMask a Remix: + + - En Remix, vaya al plugin **Deploy & run transactions**. + - En el desplegable **Entorno**, seleccione **Proveedor inyectado**. + - Esto conectará con MetaMask. Asegúrate de que MetaMask está en la red `RSK Testnet` que configuraste anteriormente. + +### Interactuar con el contrato desplegado en Remix + +Para interactuar con su contrato desplegado en la red Rootstock: + +- Cargar su contrato desplegado + - Importa el archivo `myToken.sol` a remix y compila. + +Importar archivo Solidity y compilar](/img/guides/quickstart/hardhat/compile-contract-remix.png) + +- Una vez compilado, debería ver la marca de verificación y el archivo solidiity cargado en Remix. + +Compilación exitosa](/img/guides/quickstart/hardhat/successful-compile-remix.png) + +- Elija `Deploy and Run Transactions` y en `Environment`, elija "Injected Provider - Metamask". + +Esto carga la cartera Metamask. + +Despliegue y ejecución de transacciones](/img/guides/quickstart/hardhat/deploy-and-run-tx-remix.png) + +Ahora haz clic en `Transacciones registradas` ¡interactúa con el Contrato Inteligente! Llama a sus funciones, envía transacciones y observa los resultados. Asegúrate de que tienes suficiente tRBTC en tu cartera MetaMask para las tasas de transacción. + +- Supervisar las transacciones + - Utilice Remix y MetaMask para supervisar las confirmaciones y los resultados de las transacciones. + - También puede utilizar [Rootstock Testnet Explorer](https://explorer.testnet.rootstock.io/) para ver las transacciones y las interacciones contractuales. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/index.md new file mode 100644 index 00000000..253dc8ab --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/index.md @@ -0,0 +1,39 @@ +--- +sidebar_label: Primeros pasos con el casco +sidebar_position: 100 +title: Primeros pasos con el casco +description: Empieza a crear una dApp en Rootstock utilizando Hardhat. +tags: + - guías + - desarrolladores + - contratos inteligentes + - rsk + - portainjertos + - casco + - dApps + - éteres +--- + +:::note[Before empiezas] + +> Si es nuevo en Web3 y en el desarrollo de contratos inteligentes, comience explorando la [red Rootstock](/developers/blockchain-essentials/overview/). A continuación, avance paso a paso a la Guía de inicio rápido con Hardhat para una comprensión completa de la red y empezar a escribir, probar y desplegar contratos inteligentes en Rootstock. + +> Para tu comodidad, hemos creado un [repositorio GitHub](https://github.com/rsksmart/rootstock-quick-start-guide) dedicado a esta guía. La rama [master](https://github.com/rsksmart/rootstock-quick-start-guide/tree/master) contiene el estado inicial del proyecto, mientras que la rama [feat/complete](https://github.com/rsksmart/rootstock-quick-start-guide/tree/feat/complete) presenta el proyecto completo, equipado con todas las instalaciones necesarias para tu referencia. + +> Nota: Esta guía está optimizada para Node.js versión 18 o anterior. Si estás usando una versión posterior, considera usar un gestor de versiones como [NVM](https://github.com/nvm-sh/nvm/blob/master/README.md) para cambiar a una versión compatible. + +> ¿Necesitas empezar a utilizar Hardhat rápidamente? Utilice el [Hardhat Starter Kit](/developers/quickstart/hardhat) o utilice el [Wagmi Starter Kit](https://github.com/rsksmart/rsk-wagmi-starter-kit) +> ::: + +## Navegar por la Guía + +| Recursos | Descripción | +| ------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------- | +| [Requisitos previos](/developers/requirements/) | Infórmate sobre las herramientas que necesitas para seguir esta guía. | +| [Crear un proyecto Hardhat](/developers/smart-contracts/hardhat/) | Aprenda a configurar su entorno de desarrollo con Hardhat. | +| [Configurar Hardhat para Rootstock](/developers/smart-contracts/hardhat/configure-hardhat-rootstock/) | Aprenda a configurar su proyecto Hardhat para el desarrollo en la red de pruebas y la red principal de Rootstock. | +| [Escribir contratos inteligentes](/developers/smart-contracts/hardhat/write-smart-contracts/) | Aprende a escribir contratos inteligentes. | +| [Contratos inteligentes de prueba](/developers/smart-contracts/hardhat/test-smart-contracts/) | Aprenda a probar su contrato inteligente para asegurarse de que funciona según lo esperado. | +| [Despliegue de contratos inteligentes](/developers/smart-contracts/hardhat/deploy-smart-contracts/) | Aprenda a desplegar su contrato inteligente en su entorno local y en la red Rootstock. | +| [Interactuar con el frontend](/developers/smart-contracts/hardhat/interact-with-frontend/) | Aprende a interactuar con el contrato inteligente desde la aplicación front-end. | +| [Consejos de depuración y solución de problemas](/developers/smart-contracts/hardhat/troubleshooting/) | Conozca los problemas más comunes que puede encontrarse mientras construye siguiendo esta guía y cómo puede resolverlos. | diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/interact-with-frontend.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/interact-with-frontend.md new file mode 100644 index 00000000..82f292c5 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/interact-with-frontend.md @@ -0,0 +1,373 @@ +--- +sidebar_label: Interactuar con el Front-end +sidebar_position: 106 +title: Interactuar con el Front-end +description: Aprenda a integrar su contrato inteligente Rootstock con aplicaciones front-end. +tags: + - guías + - desarrolladores + - contratos inteligentes + - rsk + - portainjertos + - casco + - dApps + - éteres +--- + +La creación de una interfaz web fácil de usar para los contratos inteligentes en la red Rootstock puede mejorar la interacción del usuario. Aquí nos centraremos en el uso de `ethers.js`, una popular biblioteca de Ethereum, para conectar tus contratos inteligentes a un front-end web. + +## Configuración del proyecto + +1. Crea una nueva carpeta llamada `frontend` y navega hasta el directorio: + +```shell + mkdir frontend + cd frontend +``` + +> Nota: Si usas el repo de inicio rápido en `master`, ya hay una carpeta frontend. Puedes `cd` en el directorio del frontend. + +2. En el directorio frontend, inicializa un proyecto Node.js: + +```shell + npm init -y +``` + +3. Instala Ethers.js: + +```shell + npm install --save éteres +``` + +## Crear archivo HTML + +- Actualizar archivo HTML + - En el directorio del frontend, abra el archivo `index.html`: + - Copie el siguiente fragmento de código y péguelo en su archivo html: + ```html + + + + + + + Aplicación Web3 con Ethers.js + + + + + + + ``` +- Éteres de importación + - Para importar la librería Ethers para interactuar con el monedero a la red, copie el fragmento de código siguiente y péguelo en la sección `` de su archivo html: + ```html + + ``` +- Crear elementos HTML dentro del cuerpo + 1. Crear un botón para activar la función de conexión del monedero. + 2. Crear un botón para activar la función para obtener saldo. + 3. Crea un elemento div para mostrar la respuesta de la dirección conectada. + 4. Crea un elemento div para mostrar la respuesta del saldo de la cartera. + ```html + +
+

Conectarse a la red Rootstock

+ + +
+
+
+ + ``` +- Importar archivo javascript + - Por último, para importar la biblioteca javascript que crearemos en un paso posterior, copie el fragmento de código siguiente y péguelo en la sección `` de su archivo html:: + ```html + + ``` + +Tu archivo `index.html` debería parecerse ahora al [archivo `index.html`](https://raw.githubusercontent.com/rsksmart/rootstock-quick-start-guide/feat/complete/frontend/index.html) en GitHub. + +## Crear funciones JavaScript + +- Crear función javascript básica + 1. En el directorio del frontend, abre el archivo `app.js`. + 2. Copie el archivo de artefactos `MyToken.json` generado al construir los contratos en `/artifacts/contracts/MyToken.sol/MyToken.json`. + 3. Copia el archivo `networks.json`. [Puede obtener el archivo en este enlace](https://github.com/jesus-iov/rootstock-quick-start-guide/blob/5cf8c1d2e50d967be9cfc653a045ca614c3c32aa/frontend/networks.json). + 4. Crea la función para esperar a que se cargue el DOM, instancia los elementos HTML (botones y divs), y declara algunas variables: + ```js + document.addEventListener('DOMContentLoaded', function () { + // Instanciación de elementos HTML + const connectButton = document.getElementById('connectButton'); + const getBalanceButton = document.getElementById('getBalanceButton'); + const walletAddressDiv = document.getElementById('walletAddress'); + const walletBalanceDiv = document.getElementById('walletBalance'); + // Instanciación de variables + let provider, account, myTokenContract; + let contractABI = []; + let networks = {}; + const contractAddress = 'Sustituir por la dirección de su contrato'; // Por ejemplo, 0xa6fb392538BaC56e03a900BFDE22e76C05fb5122 + }); + ``` +- Añade una función que obtenga la ABI y la almacene en una variable + ```js + async function fetchExternalFiles() { + // Coloca MyToken.json generado en artefactos después de compilar los contratos + let response = await fetch('MyToken.json'); + const data = await response.json(); + contractABI = data.abi; + // Coloca networks.json para establecer la red automáticamente con la función checkNetwork() + // Puedes establecerla manualmente en su lugar siguiendo esta guía https://dev.rootstock.io/resources/tutorials/rootstock-metamask/ + response = await fetch('networks.json'); + networks = await response.json(); + } + ``` +- Añadir una función que comprueba la cartera está conectado a la red Rootstock + ```js + async function checkNetwork() { + try { + // Asegúrate de que Metamask está instalado + if (!window.ethereum){ + alert('¡Por favor, instala Metamask!'); + return; + } + // Cambiar de red + await window.ethereum.request({ + method: 'wallet_switchEthereumChain', + params: [{ chainId: networks.rskTestnet.chainId }], + }); + } catch (error) { + // Este código de error indica que la cadena no se ha añadido a Metamask + if (error.code === 4902) { + // Trying to add new chain to Metamask + await window.ethereum.request({ + method: 'wallet_addEthereumChain', + params: [networks.rskTestnet], + }); + } else { + // Rethrow all other errors + throw error; + } + } + } + ``` +- Llama a la función fetchABI que carga la ABI y conecta el monedero a la red. + ```js + ¡// Obtener los datos necesarios y configurar los eventos + fetchExternalFiles().then(() => { + // Evento del botón de conexión + connectButton.addEventListener('click', async function () { + // Comprobar que la red está configurada correctamente + await checkNetwork(); + if (typeof window.ethereum !== 'undefined') { + try { + // Obtener la cuenta de Metamask + const accounts = await window.ethereum.request({ method: 'eth_requestAccounts' }); + account = accounts[0]; + // Actualizar el frente con la dirección de la cuenta + walletAddressDiv.innerHTML = `Connected account: ${account}`; + // Obtener el proveedor de red + provider = new ethers.providers.Web3Provider(window.ethereum); + // Obtener el firmante para la interacción en red + signer = provider.getSigner(); + // Activa el botón getBalanceButton + connectButton.disabled = true; + getBalanceButton.disabled = false; + } catch (error) { + console.error("Error connecting to MetaMask", error); + walletAddressDiv.innerHTML = `Error: ${error.message}`; + } + } else { + walletAddressDiv.innerHTML = `¡Por favor, instale MetaMask! `; + } + }); + ``` +- Añade una función que responda al evento de clic en el botón de obtener saldo. + ```js + // Obtener el evento del botón de saldo + getBalanceButton.addEventListener('click', async function () { + // Verificar que contractAddress es una dirección válida + if (!ethers.utils.isAddress(contractAddress)){ + alert('Por favor, verifique que contractAddress está establecido'); + return; + } + // Instanciar el contrato + myTokenContract = new ethers.Contract(contractAddress, contractABI, signer); + // Comprobar si el contrato se ha instanciado correctamente + if (myTokenContract) { + // Obtener el saldo del usuario + const balance = await myTokenContract.balanceOf(account); + // Mostrar el saldo del usuario + walletBalanceDiv.innerHTML = `MyToken Balance: ${balance} MTK`; + } + }); + ``` +- Ver el código completo + - [Enlace GitHub](https://raw.githubusercontent.com/rsksmart/rootstock-quick-start-guide/feat/complete/frontend/app.js) + ```js + document.addEventListener('DOMContentLoaded', function () { + // Instanciación de elementos HTML + const connectButton = document.getElementById('connectButton'); + const getBalanceButton = document.getElementById('getBalanceButton'); + const walletAddressDiv = document.getElementById('walletAddress'); + const walletBalanceDiv = document.getElementById('walletBalance'); + // Instanciación de variables + let provider, account, myTokenContract; + let contractABI = []; + let networks = {}; + const contractAddress = 'Sustituir con la dirección de su contract\'; // Ej. 0xa6fb392538BaC56e03a900BFDE22e76C05fb5122 + + /** + * Cargar datos de archivos JSON externos + */ + async function fetchExternalFiles() { + // Colocar MyToken.json generado en artefactos tras compilar los contratos + let response = await fetch('MyToken.json'); + const data = await response.json(); + contractABI = data.abi; + // Coloca networks.json para establecer la red automáticamente con la función checkNetwork() + // Puedes establecerla manualmente siguiendo esta guía https://dev.rootstock.io/resources/tutorials/rootstock-metamask/ + response = await fetch('networks.json'); + networks = await response.json(); + } + + /** + * Comprueba y establece la red automáticamente en caso de que no se haya hecho ya + */ + async function checkNetwork() { + try { + // Asegúrate de que Metamask está instalado + if (!window.ethereum){ + alert('¡Por favor, instala Metamask!'); + return; + } + // Cambiar de red + await window.ethereum.request({ + method: 'wallet_switchEthereumChain', + params: [{ chainId: networks.rskTestnet.chainId }], + }); + } catch (error) { + // Este código de error indica que la cadena no se ha añadido a Metamask + if (error.code === 4902) { + // Trying to add new chain to Metamask + await window.ethereum.request({ + method: 'wallet_addEthereumChain', + params: [networks.rskTestnet], + }); + } else { + // Rethrow all other errors + throw error; + } + } + } + + ¡// Obtener los datos necesarios y configurar los eventos + fetchExternalFiles().then(() => { + // Evento del botón de conexión + connectButton.addEventListener('click', async function () { + // Comprobar que la red está configurada correctamente + await checkNetwork(); + if (typeof window.ethereum !== 'undefined') { + try { + // Obtener la cuenta de Metamask + const accounts = await window.ethereum.request({ method: 'eth_requestAccounts' }); + account = accounts[0]; + // Actualizar el frente con la dirección de la cuenta + walletAddressDiv.innerHTML = `Connected account: ${account}`; + // Obtener el proveedor de red + provider = new ethers.providers.Web3Provider(window.ethereum); + // Obtener el firmante para la interacción en red + signer = provider.getSigner(); + // Activa el botón getBalanceButton + connectButton.disabled = true; + getBalanceButton.disabled = false; + } catch (error) { + console.error("Error connecting to MetaMask", error); + walletAddressDiv.innerHTML = `Error: ${error.message}`; + } + } else { + walletAddressDiv.innerHTML = `¡Por favor, instale MetaMask! `; + } + }); + + // Obtener el evento del botón de saldo + getBalanceButton.addEventListener('click', async function () { + // Verificar que contractAddress es una dirección válida + if (!ethers.utils.isAddress(contractAddress)){ + alert('Por favor, verifique que contractAddress está establecido'); + return; + } + // Instanciar el contrato + myTokenContract = new ethers.Contract(contractAddress, contractABI, signer); + // Comprobar si el contrato se ha instanciado correctamente + if (myTokenContract) { + // Obtener el saldo del usuario + const balance = await myTokenContract.balanceOf(account); + // Mostrar el saldo del usuario + walletBalanceDiv.innerHTML = `MyToken Balance: ${balance} MTK`; + } + }); + }); + }); + ``` + +### Ejecutar el frontend + +Para ejecutar el frontend, ejecute un servidor web local para probar el archivo HTML utilizando el siguiente comando: + +```shell +npx servidor http +``` + +Navegue hasta la URL `http://127.0.0.1:8080` para probar el código en el navegador y deberías obtener un resultado similar a la imagen de abajo: +Contrato Inteligente Frontend](/img/guides/quickstart/hardhat/frontend.png) + +:::tip\[Tip] + +- Asegúrese de que la red local hardhat se está ejecutando. Ejecute `npx hardhat node` en el directorio raíz para iniciar la red local. Consulte la sección [Solución de problemas y errores comunes](/developers/smart-contracts/hardhat/troubleshooting/) para solucionar errores comunes. +- Puedes ver y ejecutar el proyecto completo desde la rama [`feat/complete` branch](https://github.com/rsksmart/rootstock-quick-start-guide/tree/feat/complete). Para ello, haz git checkout en la rama `feat/complete`, ejecuta `cd frontend`, ejecuta `npm install`, y luego ejecuta `npx http-server` para ver e interactuar con el contrato inteligente desde el frontend. + ::: + +## Recursos + +Estas herramientas están específicamente diseñadas para el desarrollo de Web3, y pueden simplificar la integración de la funcionalidad de blockchain en las interfaces web. He aquí algunas herramientas y bibliotecas recomendadas que son populares en el espacio Web3, junto con breves descripciones: + +```mdx-code-block + + + 1. RainbowKit + + - RainbowKit](https://www.rainbowkit.com/) es una librería React que ofrece una solución completa de conexión de monederos. Proporciona una interfaz de conexión de billetera hermosa y fácil de usar que admite múltiples billeteras y redes. + - **Por qué usarlo:** + Es ideal para proyectos en los que desea una experiencia de conexión de billetera fluida y fácil de usar. Es fácil de integrar y administrar, especialmente en aplicaciones basadas en React. + + + + 2. Web3Modal + + - [Web3Modal](https://web3modal.com/) es una biblioteca JavaScript que proporciona un modal de conexión de billetera simple y unificado para aplicaciones Web3. Es compatible con varios proveedores de billetera y se puede usar con diferentes bibliotecas Web3. + - **Por qué usarlo:** Si necesitas comenzar a usar React o quieres una solución de conexión de billetera agnóstica al framework, Web3Modal es una excelente opción. Es personalizable y funciona bien tanto con web3.js como con ethers.js. + + + + 3. Wagmi + + - Wagmi](https://wagmi.sh/) es un conjunto de React Hooks para Ethereum que simplifica las interacciones con ethers.js. Proporciona ganchos para conexión de billetera, interacción de contrato, saldos y más. + - **Por qué usarlo:** Para los desarrolladores de React que prefieren un enfoque basado en ganchos, Wagmi ofrece una manera elegante de integrar la funcionalidad de Ethereum. Hace que la gestión de las interacciones de estado y blockchain sea más intuitiva. + + + + 4. Moralis + + - Moralis](https://moralis.io/) es una plataforma backend totalmente gestionada para aplicaciones Web3 y blockchain. Ofrece un conjunto de herramientas para autenticación, bases de datos en tiempo real, funciones en la nube y sincronización de datos blockchain. + - **Por qué usarlo:** Puede ser un ahorro de tiempo para construir una aplicación más completa con soporte backend. Maneja gran parte de la complejidad del backend y te permite centrarte en el desarrollo del front-end. + + + + 5. Foundry + + - Foundry](https://book.getfoundry.sh) es una cadena de herramientas de desarrollo de contratos inteligentes y un entorno de desarrollo fácil de usar utilizado para escribir y probar contratos inteligentes avanzados en Solidity. + + + +``` diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/test-smart-contracts.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/test-smart-contracts.md new file mode 100644 index 00000000..d85ed7c0 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/test-smart-contracts.md @@ -0,0 +1,85 @@ +--- +sidebar_label: Probar contratos inteligentes +sidebar_position: 104 +title: Probar contratos inteligentes +description: Aprenda a probar su contrato inteligente Rootstock +tags: + - guías + - desarrolladores + - contratos inteligentes + - rsk + - portainjertos + - casco + - dApps + - éteres +--- + +En esta sección, configurarás una prueba de contrato inteligente y probarás tu contrato utilizando los marcos de pruebas Mocha y Chai. Ver Automatización de DApps usando [Cucumber y Playwright](/resources/tutorials/dapp-automation-cucumber/). + +Siga estos pasos para probar el contrato inteligente. + +### Paso 1: Instalar dependencias + +Instalaremos las dependencias de pruebas de Mocha y Chai. + +Mocha es un marco de pruebas de JavaScript que se ejecuta en Node.js. Chai es una biblioteca de aserciones para el navegador y Node que puede emparejarse con cualquier framework de pruebas JavaScript. + +- Antes de escribir pruebas para su contrato de token, asegúrese de que Mocha y Chai están instalados. Para instalar las dependencias de pruebas necesarias: + +```shell + npm install --save-dev mocha@10.2.0 chai@4.2.0 @nomiclabs/hardhat-ethers@2.2.3 +``` + +### Paso 2: Crear pruebas + +1. Navegue hasta el directorio `test` en el directorio raíz de su proyecto, este es el recomendado para almacenar todos los archivos de prueba: + +```shell + prueba de cd +``` + +2. En el directorio de pruebas, abre el archivo `MyToken.test.js`, escribiremos pruebas para el contrato token usando Mocha y Chai: + +Copia el siguiente fragmento de código y pégalo en tu archivo de prueba o consulta el archivo [`MyToken.test.js`](https://raw.githubusercontent.com/rsksmart/rootstock-quick-start-guide/feat/complete/test/MyToken.test.js) en GitHub. + +```js + const { expect } = require("chai"); + const { ethers } = require("hardhat"); + + describe("MyToken", function () { + it("Debería desplegar MyToken y asignar el suministro total al propietario", async function () { + const [propietario] = await ethers.getSigners(); + + const MyToken = await ethers.getContractFactory("MyToken"); + const myToken = await MyToken.deploy(1000); + await myToken.deployed(); + + expect((await myToken.totalSupply()).toString()).to.equal('1000'); + expect((await myToken.balanceOf(owner.address)).toString()).to.equal('1000'); + }); +}); +``` + +### Paso 3: Ejecutar las pruebas + +Para ejecutar las pruebas, ejecute el siguiente comando en el directorio raíz de su proyecto. Esto ejecutará las pruebas escritas, confirmando que el contrato funciona como se esperaba. + +```shell +prueba del casco npx +``` + +Debería obtener una respuesta como la siguiente +Éxito de la prueba](/img/guides/quickstart/hardhat/test-success.png) + +Siguiendo estos pasos, tendrás instalados los marcos de pruebas necesarios y estarás bien preparado para escribir pruebas eficaces para tu contrato inteligente. + +## Enfoques y marcos de pruebas alternativos + +Además de Mocha y Chai, puede utilizar varios otros marcos y enfoques en su proyecto Hardhat. Cada uno tiene sus propias características y ventajas. + +- Jest - Marco de pruebas de JavaScript + - [Jest](https://jestjs.io/) es popular por su agradable sintaxis y su enfoque en la simplicidad. Funciona bien para probar aplicaciones JavaScript tanto frontend como backend. +- Waffle - Biblioteca de pruebas de contratos inteligentes de Ethereum + - [Waffle](https://getwaffle.io/) es una biblioteca para escribir y probar contratos inteligentes. Se utiliza a menudo con ethers.js y es conocida por su sintaxis fluida. +- Automatización de DApps Cucumber + - [Automatización de aplicaciones con Cucumber](/resources/tutorials/dapp-automation-cucumber/) diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/troubleshooting.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/troubleshooting.md new file mode 100644 index 00000000..b9ec0a85 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/troubleshooting.md @@ -0,0 +1,44 @@ +--- +sidebar_label: Depuración y resolución de problemas +sidebar_position: 106 +title: Errores comunes y consejos +description: Conozca algunos de los posibles problemas que puede encontrarse y consejos para resolverlos. +tags: + - guías + - desarrolladores + - contratos inteligentes + - rsk + - portainjertos + - casco + - dApps + - éteres +--- + +Esta sección ofrece ayuda sobre algunos posibles problemas con los que te puedes encontrar y consejos para resolverlos. + +## Errores + +- Error HH8: Hay uno o más errores en su archivo de configuración + ```shell + % npx hardhat compile + Error HH8: Hay uno o más errores en su archivo de configuración: + + * Invalid account: #0 for network: rskMainnet - Expected string, received undefined + * Cuenta inválida: #0 for network: rskTestnet - Expected string, received undefined + + Para aprender más sobre la configuración de Hardhat, por favor vaya a https://hardhat.org/config/ + + Para más información vaya a https://hardhat.org/HH8 o ejecute Hardhat con --show-stack-traces + ``` + > - FIX 1: Asegúrese de que los valores de las variables de entorno coinciden con el archivo de configuración de red hardhat `hardhat.config.js`. Para bash, ejecute `source .env` en el directorio raíz para dotenv para habilitar las variables de entorno. +- Error: Nada que compilar + ```shell + % npx hardhat compile + Nada que compilar + ``` + > - FIX 2: Borre la carpeta de artefactos y ejecute el comando `npx hardhat compile` para generar nuevos artefactos. +- Error: "GET /MiToken.json" Error (404): "No encontrado" + - Compruebe que los contratos se han compilado correctamente y que se ha generado la carpeta de artefactos. + - Comprueba que se han seguido secuencialmente todos los pasos de [interactuar con frontend](/desarrolladores/contratos-inteligentes/hardhat/interactuar-con-frontend/). +- Error: HH601: El script scripts/deploy.js no existe. + - Asegúrese de que está ejecutando el comando `npx hardhat run --network hardhat scripts/deploy.js` desde el directorio raíz. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/write-smart-contracts.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/write-smart-contracts.md new file mode 100644 index 00000000..4ff11012 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/02-hardhat/write-smart-contracts.md @@ -0,0 +1,76 @@ +--- +sidebar_label: Escribir un contrato inteligente +sidebar_position: 103 +title: Escribir un contrato inteligente +description: Aprende a escribir un contrato inteligente utilizando Solidity y OpenZeppellin +tags: + - guías + - desarrolladores + - contratos inteligentes + - rsk + - portainjertos + - casco + - dApps + - éteres +--- + +En esta sección, aprenderemos a escribir un contrato inteligente utilizando la [biblioteca OpenZeppelin](https://www.openzeppelin.com/contracts) y Solidity. OpenZeppelin es ampliamente utilizado por su código base seguro, estandarizado y validado por la comunidad, que simplifica el desarrollo de contratos inteligentes robustos y seguros. + +## Crear un contrato inteligente + +### Paso 1: Instalar los contratos OpenZeppelin + +Ejecute el siguiente comando para instalar la biblioteca de contratos inteligentes reutilizables de OpenZeppelin. + +```shell + npm install @openzeppelin/contratos +``` + +#### Paso 2: Crear un contrato de token + +- Navegue hasta el directorio `contracts` en el directorio raíz del proyecto de inicio rápido: + +```shell + contratos cd +``` + +- En el directorio de contratos, abra el archivo `MyToken.sol` para su contrato de token: + +Para configurar un token ERC20, copie el siguiente fragmento de código y péguelo en su archivo de token o consulte el archivo completo [`MyToken.sol`](https://raw.githubusercontent.com/rsksmart/rootstock-quick-start-guide/feat/complete/contracts/MyToken.sol) en GitHub. + +```shell + // SPDX-Licencia-Identificador: MIT + pragma solidity ^0.8.20; + + import "@openzeppelin/contracts/token/ERC20/ERC20.sol"; + + contract MyToken is ERC20 { + constructor(uint256 initialSupply) ERC20("MyToken", "MTK") { + _mint(msg.sender, initialSupply); + } + } +``` + +Este contrato define un token `ERC20` llamado `MyToken` con el símbolo `MTK`, utilizando la implementación estándar ERC20 de OpenZeppelin. + +## Redactar el contrato + +Para construir el contrato, ejecute el siguiente comando en el directorio raíz del proyecto. + +```shell +npx hardhat compile +``` + +Esto compilará tus contratos inteligentes y generará artefactos: + +```shell +% npx hardhat compile +Descargando compilador 0.8.20 +Compilado 6 archivos Solidity con éxito (objetivo evm: paris). +``` + +--- + +## Siguiente + +- [Pruebe su Contrato Inteligente](/developers/smart-contracts/hardhat/test-smart-contracts/) para asegurarse de que funciona como se espera. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/03-interface-registry/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/03-interface-registry/index.md new file mode 100644 index 00000000..d6afec8f --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/03-interface-registry/index.md @@ -0,0 +1,57 @@ +--- +sidebar_label: Registro de interfaces +sidebar_position: 300 +title: Registro universal de interfaces de contratos inteligentes +description: Consulte la interfaz estándar ERC1820, el soporte de direcciones y la implementación de contratos inteligentes. +tags: + - contratos inteligentes + - rsk + - portainjertos + - desarrolladores + - registro de interfaces +--- + +El estándar ERC1820 define un contrato inteligente de registro universal en el que cualquier dirección (contrato o cuenta normal) puede registrar qué interfaz admite y qué contrato inteligente es responsable de su implementación. + +## Descripción + +Este estándar define un registro donde los contratos inteligentes y las cuentas regulares pueden publicar qué funcionalidad implementan, ya sea directamente o a través de un contrato proxy. + +Cualquiera puede consultar este registro para saber si una dirección específica implementa una interfaz determinada y qué contrato inteligente se encarga de su implementación. + +Este registro puede desplegarse en cualquier cadena y comparte la misma dirección en todas las cadenas. + +Las interfaces con ceros (0) como últimos 28 bytes se consideran interfaces ERC165, y este registro REENVIARÁ la llamada al contrato para comprobar si implementa la interfaz. + +Este contrato también actúa como caché del ERC165 para reducir el consumo de gas. + +## Motivación + +[EIP1820](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1820.md) +permite a los contratos registrar la interfaz y consultar el registro, evitando errores de comunicación que pueden dar lugar a la pérdida de fondos. + +Por ejemplo, con un contrato inteligente ERC20, un error puede provocar la quema de tokens. +Aunque el estándar de tokens ERC20 está bien documentado y bien implementado en general, contiene un error. Este fallo ha provocado pérdidas de tokens por valor de millones de dólares estadounidenses. Con la función `transfer`, sólo puedes enviar tokens a una cuenta externa. Si utilizas la función `transfer` para enviar tokens a un contrato inteligente (que no es una cuenta externa), verás una transacción exitosa, pero el contrato nunca recibirá los tokens. Esto destruye los tokens para siempre, ya que no se pueden recuperar. Al utilizar la función incorrecta, ¡varios usuarios han perdido sus tokens para siempre! + +El estándar de token ERC777 resuelve este problema utilizando el registro de interfaz EIP1820, y es compatible con el estándar de token ECR20. + +Con el fin de permitir implementaciones basadas en el estándar de tokens ERC777, +así como cualquier otro contrato inteligente que se beneficie del uso de +un registro de interfaz de contrato inteligente universal, +Rootstock ha desplegado una implementación del registro EIP1820 tanto en su +[Mainnet](https://explorer.rootstock.io/address/0x1820a4b7618bde71dce8cdc73aab6c95905fad24), +y [Testnet](https://explorer.testnet.rootstock.io/address/0x1820a4b7618bde71dce8cdc73aab6c95905fad24). + +## Enlaces e información + +Original: + +- [EIP1820](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1820.md) +- Comparación entre [ERC777 y ERC20](https://hackernoon.com/erc777-is-the-new-token-standard-replacing-the-erc20-fd6319c3b13) +- Comparación de [ERC777 y ERC223 con ERC20](https://101blockchains.com/erc20-vs-erc223-vs-erc777/) + +Portainjerto: + +- [Contrato inteligente EIP1820 desplegado en la red principal Rootstock](https://explorer.rootstock.io/address/0x1820a4b7618bde71dce8cdc73aab6c95905fad24) +- [Rootstock Testnet desplegado EIP1820 smartcontract](https://explorer.testnet.rootstock.io/address/0x1820a4b7618bde71dce8cdc73aab6c95905fad24) +- Propuesta de mejora de portainjertos correspondiente: [RSKIP148](https://github.com/rsksmart/RSKIPs/blob/e0ac990679a2e6f476e41db0c1050132cd2b1bfc/IPs/RSKIP148.md) diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/04-verify-smart-contracts/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/04-verify-smart-contracts/index.md new file mode 100644 index 00000000..efe38a22 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/04-verify-smart-contracts/index.md @@ -0,0 +1,178 @@ +--- +sidebar_label: Verificación de contratos inteligentes con el complemento Hardhat Verify +sidebar_position: 400 +title: Verificación de un contrato inteligente mediante el complemento de verificación Hardhat +description: Configuración del complemento de verificación Hardhat para Rootstock +tags: + - casco + - tutorial + - desarrolladores + - inicios rápidos + - rsk + - portainjertos +--- + +Los contratos inteligentes son la columna vertebral de las aplicaciones descentralizadas (dApps). Automatizan acuerdos y procesos, pero su código puede ser complejo y propenso a errores. Verificar tus contratos inteligentes es crucial para garantizar que funcionan según lo previsto. + +Este tutorial le guiará a través de la verificación de sus contratos utilizando el Plugin de Verificación Hardhat en el Explorador Blockscout de Rootstock. Este complemento simplifica la verificación de los contratos inteligentes Solidity desplegados en la red Rootstock. Al verificar los contratos, permite a Blockscout, un explorador de bloques de código abierto, vincular el código fuente de su contrato con su bytecode desplegado en la blockchain, lo que permite una interacción más fiable con el código. + +En este tutorial, realizaremos los siguientes pasos: + +- Configure su entorno hardhat config en su proyecto +- Utilice el complemento `hardhat-verify` para verificar la dirección de un contrato. + +## Requisitos previos + +Para seguir este tutorial, debes tener conocimientos de lo siguiente: + +- Casco +- Conocimientos básicos de contratos inteligentes + +:::note[Hardhat Starter dApp] + +Se ha creado una [Hardhat Starter dApp](https://github.com/rsksmart/rootstock-hardhat-starterkit) con una configuración preestablecida para la red Rootstock. Clona y sigue las instrucciones del README para configurar el proyecto. Nota: Establecer las variables `.env` para que coincidan con el archivo `hardhat.config.ts`, si se utiliza la dApp de inicio para este tutorial. + +::: + +## ¿Qué es hardhat-verify? + +[Hardhat](https://hardhat.org/) es un entorno de desarrollo completo para la compilación, despliegue y verificación de contratos. +El [hardhat-verify plugin](https://hardhat.org/hardhat-runner/plugins/nomicfoundation-hardhat-verify) soporta la verificación de contratos en el [Rootstock Blockscout Explorer](https://rootstock.blockscout.com/). + +> Nota: El plugin `hardhat-verify` estará disponible próximamente en el [Rootstock Explorer](https://explorer.rootstock.io/). + +### Instalación + +```bash +npm install --save-dev @nomicfoundation/hardhat-verify +``` + +Y añade el siguiente código a tu archivo `hardhat.config.ts`: + +```bash +require("@nomicfoundation/hardhat-verify"); +``` + +O, si estás usando TypeScript, añade esto a tu hardhat.config.ts: + +```bash +importar "@nomicfoundation/hardhat-verify"; +``` + +### Utilización + +Necesitas añadir la siguiente configuración de Etherscan a tu archivo `hardhat.config.ts`: + +```bash +// Configuración de Hardhat +const config: HardhatUserConfig = { + defaultNetwork: "hardhat", + networks: { + hardhat: { + // Si quieres hacer alguna bifurcación, descomenta esto + // bifurcación: { + // url: MAINNET_RPC_URL + // } + }, + localhost: { + url: "http://127.0.0.1:8545", + }, + rskMainnet: { + url: RSK_MAINNET_RPC_URL, + chainId: 30, + gasPrice: 60000000, + accounts:[PRIVATE_KEY] + }, + rskTestnet: { + url: RSK_TESTNET_RPC_URL, + chainId: 31, + gasPrice: 60000000, + accounts:[PRIVATE_KEY] + }, + }, + namedAccounts: { + deployer: { + default: 0, // Por defecto es la primera cuenta + mainnet: 0, + }, + owner: { + default: 0, + }, + }, + solidity: { + compilers: [ + { + version: "0.8.24", + }, + ], + }, + sourcify: { + enabled: false + }, + etherscan: { + apiKey: { + // No es requerido por blockscout. Puede ser cualquier cadena no vacía + rskTestnet: 'RSK_TESTNET_RPC_URL', + rskMainnet: 'RSK_MAINNET_RPC_URL' + }, + customChains: [ + { + network: "rskTestnet", + chainId: 31, + urls: { + apiURL: "https://rootstock-testnet.blockscout.com/api/", + browserURL: "https://rootstock-testnet.blockscout.com/", + } + }, + { + network: "rskMainnet", + chainId: 30, + urls: { + apiURL: "https://rootstock.blockscout.com/api/", + browserURL: "https://rootstock.blockscout.com/", + } + }, + + ] + }, +}; + +export default config; +``` + +Ahora, ejecute la tarea de verificación, pasando la dirección del contrato, +la red donde está desplegado, y cualquier otro argumento que se utilizó para desplegar el contrato: + +```bash +npx hardhat verify --network rskTestnet DEPLOYED_CONTRACT_ADDRESS +``` + +o + +```bash +npx hardhat verify --network rskMainnet DEPLOYED_CONTRACT_ADDRESS +``` + +:::tip\[Tip] + +- Sustituya `DEPLOYED_CONTRACT_ADDRESS` por la dirección del contrato. +- Esto puede obtenerse del archivo `MockERC721.json` que contiene las direcciones y abi en la carpeta `deployments/network`. + +::: + +**La respuesta debería ser así:** + +```bash +npx hardhat verify --network rskTestnet 0x33aC0cc41B11282085ff6db7E1F3C3c757143722 +Enviado con éxito el código fuente del contrato +contracts/ERC721.sol:MockERC721 en 0x33aC0cc41B11282085ff6db7E1F3C3c757143722 +para su verificación en el explorador de bloques. Esperando el resultado de la verificación... +Verificado con éxito el contrato MockERC721 en el explorador de bloques. +https://rootstock-testnet.blockscout.com/address/0x33aC0cc41B11282085ff6db7E1F3C3c757143722#code +``` + +## Recursos + +- Visite [hardhat-verify](https://hardhat.org/hardhat-runner/plugins/nomicfoundation-hardhat-verify#hardhat-verify) +- Visite [blockscout](https://docs.blockscout.com/for-users/verifying-a-smart-contract/hardhat-verification-plugin) +- [Kit de iniciación al casco para portainjertos](https://github.com/rsksmart/rootstock-hardhat-starterkit) diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/05-foundry/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/05-foundry/index.md new file mode 100644 index 00000000..39e56329 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/05-foundry/index.md @@ -0,0 +1,202 @@ +--- +section_position: 200 +sidebar_label: Primeros pasos con Foundry +title: Primeros pasos con Foundry +description: Cómo escribir, probar y desplegar contratos inteligentes con Foundry +tags: + - rsk + - fundición + - desarrolladores + - herramientas para desarrolladores + - portainjertos + - pruebas + - dApps + - contratos inteligentes +--- + +En esta guía, aprenderemos sobre Foundry y sus beneficios para el desarrollo de contratos inteligentes, cómo configurar tu entorno, crear un proyecto Foundry y ejecutar un script de despliegue. + +## Requisitos previos + +Para empezar a utilizar Foundry, asegúrese de que están instaladas las siguientes herramientas: + +- El compilador [Rust](https://rust-lang.org/) +- Gestor de paquetes de carga + +> Para una instalación sencilla de las herramientas anteriores, utilice el [rustup installer](https://rustup.rs). + +## Instalación + +Para instalar, utilice Foundryup. Foundryup es el instalador de la cadena de herramientas de Foundry. Puedes encontrar más información en [Foundry README](https://github.com/foundry-rs/foundry/blob/master/foundryup/README.md). + +```bash +curl -L https://foundry.paradigm.xyz | bash +``` + +Ejecutar foundryup por sí mismo instalará los últimos binarios precompilados (nightly): `forge`, `cast`, `anvil`, y `chisel`. + +> Visite las [guías de instalación](https://book.getfoundry.sh/getting-started/installation) para obtener más información. + +## Crear un proyecto de fundición + +Para iniciar un nuevo proyecto con Foundry, utilice [forge init](https://book.getfoundry.sh/reference/forge/forge-init.html). + +```bash +forge init hello_foundry +``` + +> Consulte más detalles sobre cómo [crear un nuevo proyecto](https://book.getfoundry.sh/projects/creating-a-new-project) en la guía de Foundry. + +## Redacte su primer contrato + +Veamos la estructura de archivos de un proyecto de fundición por defecto: + +```bash +$ cd hello_foundry +$ tree . -d -L 1 +. +├── lib +├── script +├── src +└── test + +4 directorios. +``` + +El directorio `src` contiene el contador del contrato inteligente con la prueba escrita en el directorio `test`. Ahora, vamos a construir el proyecto de fundición. + +```bash +construcción de forja +``` + +Y luego haz pruebas. + +```bash +prueba de forja +``` + +## Despliegue del contrato en el patrón + +Para implementar el contrato de contador en la red principal o de prueba de Rootstock, configure Foundry estableciendo una url RPC de Rootstock y una clave privada de una cuenta financiada con tRBTC. + +### Configuración del entorno + +Una vez que tengas una cuenta con una clave privada, crea un archivo `.env` en la raíz del proyecto de foundry y añade las variables. + +Foundry carga automáticamente un archivo `.env` presente en el directorio del proyecto. + +El archivo `.env` debe seguir este formato: + +```bash +ROOTSTOCK_RPC_URL=https://rpc.testnet.rootstock.io/{YOUR_APIKEY} +PRIVATE_KEY=0x... +``` + +En la raíz del proyecto, ejecute: + +```bash +# Para cargar las variables en el archivo .env +source .env +``` + +### Modificar el script de implantación + +Modifique el script de despliegue del contador de despliegue en el directorio `scripts` para utilizar la clave privada modificando el método de ejecución, vea el siguiente ejemplo: + +```solidity +// SPDX-Licencia-Identificador: UNLICENSED +pragma solidity ^0.8.13; + +import {Script, console} from "forge-std/Script.sol"; + +import "../src/Counter.sol"; + + +contract CounterScript is Script { + function setUp() public {} + + function run() public { + vm.startBroadcast(vm.envUint("PRIVATE_KEY")); + + new Counter(); + + vm.stopBroadcast(); + + } +} + +``` + +Por defecto, los scripts se ejecutan llamando a la función llamada `run` en el punto de entrada. + +```solidity +uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY"); +``` + +> - PRECAUCIÓN: Ten cuidado cuando expongas claves privadas en un archivo `.env` y las cargues en programas. +> - Esto sólo se recomienda para su uso con desplegadores sin privilegios o para configuraciones locales / de prueba. + +Al llamar a `vm.startBroadcast()`, la creación del contrato será registrada por Forge, y podemos difundir la transacción para desplegar el contrato en la cadena. + +### Ejecutar el script de despliegue + +Utilizaremos Forge para ejecutar nuestro script y emitir las transacciones - esto puede tardar un poco, ya que Forge también espera los recibos de las transacciones. + +```bash +forge script script/Contador.s.sol --rpc-url $ROOTSTOCK_RPC_URL --broadcast --legacy +``` + +:::info\[Info] + +- [EIP-1559](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1559.md) no es compatible o no está activado en la url RPC de Rootstock. +- La bandera `--legacy` se pasa para usar transacciones legacy en lugar de `EIP-1559`. + +::: + +El resultado debería ser el siguiente: + +```bash +[⠰] Compilando... +No hay archivos modificados, la compilación se ha omitido +El script se ha ejecutado correctamente. + +== Logs == + Contador: + +## Configurando 1 EVM. + +========================== + +Cadena 31 + +Precio estimado del gas: 0.065164 gwei + +Gas total estimado usado para el script: 138734 + +Cantidad estimada requerida: 0.000009040462376 ETH + +========================== +## +Enviando transacciones [0 - 0]. +⠁ [00:00:00] [###############################################################################################################################################] 1/1 txes (0.0s)## +Esperando recibos. +⠉ [00:00:25] [###########################################################################################################################################] 1/1 recibos (0.0s) +##### 31 +✅ [Éxito]Hash: 0x015de35ffae94f491d4630f2aec84c49ae8170d5ecf3f4c1cdc8718bc4a00052 +Dirección del contrato: 0x64B24E046259042e16a337Be4648CeAAF8Eb72C6 +Bloque: 5071408 +Gas utilizado: 106719 + +========================== + +EJECUCIÓN ONCHAIN COMPLETA Y CON ÉXITO. +Total pagado: 0. ETH (106719 gas * avg 0 gwei) + +Transacciones guardadas en: /hello_foundry/broadcast/Counter.s.sol/31/run-latest.json + +Valores sensibles guardados en: /hello_foundry/cache/Counter.s.sol/31/run-latest.json +``` + +> El directorio de difusión se actualizará automáticamente con el último resultado de la implantación. + +> Consulte la [documentación de implantación de la fundición](https://book.getfoundry.sh/tutorials/solidity-scripting#deploying-our-contract). diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/contract-addresses.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/contract-addresses.md new file mode 100644 index 00000000..14641696 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/contract-addresses.md @@ -0,0 +1,36 @@ +--- +sidebar_position: 250 +title: Direcciones de los contratos de portainjertos +sidebar_label: Direcciones contractuales +tags: + - rsk + - portainjertos + - desarrolladores + - inicios rápidos + - contratos inteligentes + - direcciones de los contratos +description: Todas las direcciones contractuales en Rootstock. +--- + +Aquí puede encontrar una lista de direcciones de contratos en Rootstock. +Para obtener información sobre las rutas de derivación, consulte la sección [Direcciones basadas en cuentas](/conceptos/direcciones basadas en cuentas/) o [Verificar la propiedad de la dirección](/desarrolladores/contratos inteligentes/verificar-la-propiedad-de-la-dirección/). + +:::note\[Note] + +- [Metadatos del contrato de portainjertos](https://github.com/rsksmart/rsk-contract-metadata) +- [Metadatos del contrato de la red de pruebas de portainjertos](https://github.com/rsksmart/rsk-testnet-contract-metadata) +- [Portainjerto - DefiLlama](https://defillama.com/chain/Rootstock) + ::: + +## Lista de direcciones contractuales + +| Símbolo | Nombre | Ficha estándar | Red | Dirección del contrato | +| --------------------------------- | ------------------------------------------------------------------- | ---------------------- | ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------- | +| [RIF](/conceptos/rif-suite/token) | Ficha RIF | ERC677 | Portainjerto | [0x2acc95...](https://explorer.rootstock.io/address/0x2acc95758f8b5f583470ba265eb685a8f45fc9d5) | +| DOC | [Dólar en cadena](https://moneyonchain.com/doc-bitcoin-stablecoin/) | CEI20 | Portainjerto | [0xe70069...](https://explorer.rootstock.io/address/0xe700691da7b9851f2f35f8b8182c69c53ccad9db) | +| USDRIF | [RIF Dólar estadounidense](https://rifonchain.com/) | ERC20, ERC165, ERC1967 | Portainjerto | [0x3a15461...](https://explorer.rootstock.io/address/0x3a15461d8ae0f0fb5fa2629e9da7d66a794a6e37) | +| RIFP | [RIFPro](https://rif.moneyonchain.com/metrics) | CEI20 | Portainjerto | [0xf4d27c5...](https://explorer.rootstock.io/address/0xf4d27c56595ed59b66cc7f03cff5193e4bd74a61) | +| BPro | [BitPro](https://moneyonchain.com/bpro-income-for-bitcoin-holders/) | CEI20 | Portainjerto | [0x440cd83...](https://explorer.rootstock.io/address/0x440cd83c160de5c96ddb20246815ea44c7abbca8) | +| BTCX | [BTCX](https://moneyonchain.com/btcx-leveraged-bitcoin/) | | Portainjerto | [0xf773b5...](https://explorer.rootstock.io/address/0xf773b590af754d597770937fa8ea7abdf2668370) | +| RIFX | [RIFX](https://rif.moneyonchain.com/metrics) | | Portainjerto | [0xcff3fca...](https://explorer.rootstock.io/address/0xcff3fcaec2352c672c38d77cb1a064b7d50ce7e1) | +| WRBTC | RBTC envuelto | CEI20 | Portainjerto | [0x542FDA3...](https://rootstock.blockscout.com/token/0x542FDA317318eBf1d3DeAF76E0B632741a7e677d) | diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/index.md new file mode 100644 index 00000000..17e23bb9 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/index.md @@ -0,0 +1,22 @@ +--- +sidebar_label: Desarrollo de contratos inteligentes +sidebar_position: 5 +title: Despliegue de Contratos Inteligentes en Bitcoin +tags: + - portainjertos + - casco + - contratos inteligentes + - dApps +description: Aprenda a escribir, interactuar y desplegar contratos inteligentes en Bitcoin. +--- + +Empiece a desplegar dApps en Rootstock utilizando Hardhat, Wagmi, Remix y otras herramientas compatibles con EVM. + +| Recursos | Descripción | +| -------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | +| [Introducción a Hardhat](/developers/smart-contracts/hardhat/) | Empieza a crear una dApp en Rootstock utilizando Hardhat. | +| [Introducción a Foundry](/developers/smart-contracts/foundry/) | Cómo escribir, probar y desplegar contratos inteligentes con Foundry | +| [Direcciones de contrato](/desarrolladores/contratos-inteligentes/direcciones-de-contrato) | Lista de direcciones contractuales en Rootstock. | +| [Verificar la propiedad de la dirección](/developers/smart-contracts/verify-address-ownership/) | Verificar la propiedad de la dirección con Metamask Wallet. | +| [Registro de interfaces](/desarrolladores/contratos-inteligentes/registro-de-interfaces/) | Consulte la interfaz estándar ERC1820, el soporte de direcciones y la implementación de contratos inteligentes. | +| [Verificar contratos inteligentes utilizando el plugin Hardhat Verify](/developers/smart-contracts/verify-smart-contracts) | Configuración del complemento de verificación Hardhat para Rootstock. | diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/verify-address-ownership.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/verify-address-ownership.md new file mode 100644 index 00000000..4dfd3694 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/05-smart-contracts/verify-address-ownership.md @@ -0,0 +1,242 @@ +--- +sidebar_position: 300 +sidebar_label: Verificar la propiedad de la dirección +title: Verificar la propiedad de la dirección con Metamask Wallet +description: Confirme que posee una dirección Rootstock utilizando el Gestor de identidades RIF +tags: + - metamáscara + - dirección + - cuenta + - contratos inteligentes +--- + +Supongamos que necesita recibir una transferencia de RBTC, +o tokens en la red Rootstock, +por primera vez. +Para ello, debe crear un monedero y conectarlo a la red Rootstock. + +Sin embargo, puede que no esté seguro de si realmente "controla" las direcciones del monedero. +Es comprensible, porque es la primera vez que lo utilizas. +Esa preocupación también tiene una base técnica - +necesitas **estar seguro** de que eres **capaz de firmar** transacciones en esta dirección, +antes de pedir a otros que te envíen criptodivisas o tokens a esta dirección. + +Aquí demostraremos exactamente cómo hacerlo, +y estar seguro de que realmente "controlas" una dirección en particular. +Todo lo que necesitas es Chrome (navegador web) y MetaMask (extensión del navegador). +Usted no necesita ningún saldo RBTC para hacerlo. + +## Primeros pasos + +:::tip[Install MetaMask] + +Puede utilizar la herramienta [metamask-landing.rifos.org](https://metamask-landing.rifos.org/) para descargar/instalar Metamask y añadir la red personalizada Rootstock o seguir los pasos indicados en [metamask.io](https://metamask.io/). + +::: + +En Chrome, visita [metamask.io](https://metamask.io/), +y sigue las instrucciones para instalar esta extensión en tu navegador. +Si estás haciendo esto por primera vez, +necesitarás generar una _frase semilla_, +y es extremadamente importante que la registres en algún sitio. + +### Habilitar sólo una extensión de navegador Web3 + +Si tiene más de una extensión de navegador Web3 instalada, +por ejemplo, si tiene MetaMask, Liquality o Nifty, +tenga en cuenta que pueden entrar en conflicto entre sí. + +Pega `chrome://extensions/` en tu barra de direcciones, +para ver todas las extensiones del navegador que tienes instaladas. +Comprueba que sólo tienes MetaMask instalada, **o** +si tienes otras extensiones del navegador Web3, +debes desactivar todas las demás haciendo clic en los botones de alternancia. + +![](/img/developers/verify-address-ownership/rif-identity-metamask-disable-other-web3-extensions.png) + +:::info\[Optional] + +Para una mejor experiencia de usuario, puede que también desee + +- Haga clic en el icono de extensiones (forma de rompecabezas), y en el desplegable, +- Haz clic en el icono de la chincheta junto a MetaMask para asegurarte de que siempre esté visible. + +::: + +![](/img/developers/verify-address-ownership/rif-identity-metamask-pin-extension-dropdown.png) + +### Desbloquear MetaMask + +Tras instalar la extensión o iniciar tu navegador, +MetaMask debería mostrar una ventana emergente pidiéndote que desbloquees la cuenta. +Introduce tu contraseña de MetaMask. +(Ten en cuenta que ésta _no_ es la misma que tu frase semilla). + +Si no aparece, puede introducir manualmente +`chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/home.html#unlock` +en su barra de direcciones para navegar hasta allí en "vista expandida", +en lugar de dentro de una ventana emergente. + +![](/img/developers/verify-address-ownership/rif-identity-metamask-unlock.png) + +### Añadir red personalizada para Rootstock + +MetaMask sólo contiene configuraciones de red para conectarse a Ethereum por defecto. +Para conectarse a Rootstock necesitará añadir configuraciones de red de Rootstock. + +Tiene la opción de añadir manualmente +[Rootstock Mainnet network configuration to MetaMask](/dev-tools/wallets/metamask/). + +Alternativamente, puede hacerlo automáticamente, +visitando [identidad.rifos.org](https://identity.rifos.org/), +y cuando intente conectarse usando MetaMask, +se le presentará lo siguiente: + +![](/img/developers/verify-address-ownership/rif-identity-metamask-auto-network-1.png) + +Haz clic en "RSK Mainnet". MetaMask mostrará esta ventana emergente: + +![](/img/developers/verify-address-ownership/rif-identity-metamask-auto-network-2.png) + +Haga clic en "Aprobar". Esto rellenará automáticamente la configuración de red para usted. + +![](/img/developers/verify-address-ownership/rif-identity-metamask-auto-network-3.png) + +A continuación, haga clic en "Cambiar de red" para conectarse a la red principal del Rootstock. + +## Verificación de su cuenta Rootstock + +En este punto, deberías tener todo configurado: +Tienes un monedero instalado, +ese monedero está conectado a la RSK Mainnet, +y tienes direcciones dentro de ese monedero. + +Ya puedes comprobar que puedes utilizar tu monedero para firmar mensajes. + +### Ver el historial de transacciones + +En MetaMask, puedes consultar el historial de transacciones de una dirección concreta +seleccionando la pestaña "Actividad" en la pantalla principal. + +> "Vista ampliada": \`chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/home.html#\`\` + +![](/img/developers/verify-address-ownership/rif-identity-metamask-transaction-history.png) + +Si su ficha de actividad está vacía, como la de arriba, +significa que hay cero transacciones en esta dirección. +Copiemos la dirección haciendo clic en ella. +Se encuentra cerca de la parte superior, empieza por `0x`, +y debería estar bajo una etiqueta similar a "Cuenta 1". + +### Visitar el explorador de bloques + +Comprobemos la dirección que acaba de copiar +en el explorador de bloques de Rootstock. + +Visite `explorer.rsk.co/dirección/${YOUR_ADDRESS}`. +Sustituya `${YOUR_ADDRESS}` por la dirección copiada anteriormente de MetaMask. +Por ejemplo, si has copiado `0xdfc0e6361fd1846a223e2d7834a5ebd441a16dd4`, +la URL será `https://explorer.rsk.co/address/0xdfc0e6361fd1846a223e2d7834a5ebd441a16dd4`. + +![](/img/developers/verify-address-ownership/rif-identity-metamask-block-explorer-address-not-found.png) + +Es posible que aparezca el mensaje "No encontrado". +Esto no significa necesariamente que la cuenta no exista. +Significa que simplemente no hay transacciones en la cadena de bloques en esta dirección. + +### Visite el Gestor de identidades RIF + +Hasta ahora, no muy bien, ¿verdad? +... Nada de lo que hemos visto hasta ahora le asegura +que efectivamente controla esta dirección. + +Aquí es donde entra en juego el Gestor de Identidades de RIF. +Esta DApp permite verificar si controlamos esta dirección. +Lo hará firmando un mensaje que **no** es una transacción de blockchain. + +Visite [identity.rifos.org](https://identity.rifos.org/). + +![](/img/developers/verify-address-ownership/rif-identity-metamask-visit.png) + +Haga clic en "Conectar su cartera". + +![](/img/developers/verify-address-ownership/rif-identity-metamask-connect-wallet.png) + +Seleccione "Metamáscara". + +> Ten en cuenta que si tienes varias extensiones de navegador Web3 instaladas, +> deshabilítalas todas excepto una. +> Si no, esto confunde a la mayoría de las DApps incluyendo RIF Identity Manager, +> y puede que no veas MetaMask aquí como resultado. +> Consulta la sección "antes de empezar" para más detalles. + +### Permiso de conexión al sitio MetaMask + +Aparecerá una ventana emergente de MetaMask, +, que básicamente le pregunta si confía en el Gestor de identidades de RIF. + +![](/img/developers/verify-address-ownership/rif-identity-metamask-connect-site-permission.png) + +Haga clic en "Siguiente". +Esto permite MetaMask para interactuar con RIF Identity Manager + +MetaMask mostrará entonces otra ventana emergente, +preguntándote si quieres permitir que el Gestor de identidades de RIF +vea las direcciones de tus cuentas. + +![](/img/developers/verify-address-ownership/rif-identity-metamask-view-addresses-permission.png) + +Haz clic en "Conectar". +Esto permite a MetaMask ver las direcciones de tus cuentas. + +### Autenticación de identidad RIF + +Al conceder estos permisos, +el Administrador de Identidades DApp +le presenta otra ventana emergente MetaMask. + +![](/img/developers/verify-address-ownership/rif-identity-metamask-sign-authentication-text-message.png) + +Esta vez, te pide que firmes un mensaje de texto, +que debería tener un aspecto similar al siguiente: + +```text +¿Está seguro de que desea iniciar sesión en la Bóveda de Datos RIF? +URL: https://data-vault.identity.rifos.org +Código de verificación: ${SOME_RANDOM_VALUE} +``` + +Haga clic en "Firmar". +Cuando hagas esto, ¡sucederá la **parte crucial**! + +- MetaMask utiliza la **clave privada** correspondiente a la dirección + para firmar ese mensaje. +- El mensaje firmado se transmite al backend del Gestor de identidades RIF, + , que realiza una verificación de firma digital, + que utiliza para confirmar si efectivamente ha sido firmado por esta dirección concreta. +- Dado que se trata de un mensaje de texto sin formato, + y no implica añadir una transacción a la blockchain, + no es necesario pagar tasas de gas, + y, por tanto, su saldo de RBTC puede ser cero. + +Esto es perfecto para las cuentas recién generadas. + +### Comprobar el salpicadero + +Una vez que haya firmado el mensaje y se haya verificado, +verá el panel de control del Gestor de identidades de RIF. + +![](/img/developers/verify-address-ownership/rif-identity-metamask-dashboard.png) + +Comprueba que el campo "Persona Address" que aparece aquí **coincide** +con la dirección de tu cuenta en MetaMask. + +![](/img/developers/verify-address-ownership/rif-identity-metamask-dashboard-persona-address.png) + +Eso es todo: ahora puede estar seguro de que controla esta dirección en la red principal de Rootstock. + +## Recursos + +- [Verificar contratos inteligentes con SolidityScan](https://blog.rootstock.io/noticia/rootstock-guide-to-verifying-smart-contracts-with-solidityscan/) +- [Herramientas de desarrollo](/dev-tools/) +- [Verificación de contratos inteligentes mediante el complemento de verificación Hardhat para Rootstock](/developers/smart-contracts/verify-smart-contracts/) diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/_category_.yml b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/_category_.yml new file mode 100644 index 00000000..cd27bc79 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/_category_.yml @@ -0,0 +1,5 @@ +label: Relé RIF +position: 2 +link: + type: índice-generado + slug: /desarrolladores/integrate/rif-relay diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/architecture.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/architecture.md new file mode 100644 index 00000000..904d8385 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/architecture.md @@ -0,0 +1,278 @@ +--- +sidebar_label: Arquitectura +sidebar_position: 980 +title: RIF Relay - Arquitectura +tags: + - rif + - sobre + - relé + - integrar +description: Arquitectura de relés RIF +--- + +El sistema de retransmisión RIF está diseñado para lograr el patrocinio de transacciones a bajo coste. El coste del servicio de retransmisión proporcionado por los "patrocinadores" se acuerda entre las partes fuera de la cadena. El bajo coste de las transacciones en Rootstock (RSK) contribuye también a mantener bajos los costes generales del servicio. + +El sistema de relés RIF está formado por varios componentes, algunos esenciales y otros auxiliares. + +A continuación se ofrece una visión general al respecto: + +**En cadena**, el sistema no puede funcionar sin sus Contratos Inteligentes, que engloban las Carteras Inteligentes más el Centro de Retransmisión y los Verificadores. + +\*\*Fuera de la cadena, se necesita al menos un servidor de retransmisión para interactuar con los contratos. Sin un Servidor de Retransmisión, no se pueden crear y enviar sobres a los contratos. + +A continuación se amplían los detalles de cada uno de estos componentes, así como un glosario introductorio. + +### Glosario + +| Plazo | Descripción | +| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Patrocinador | Un tercero que paga el gas consumido por una transacción patrocinada (véase más abajo) enviándola a la blockchain. | +| Transacción patrocinada | Transacción enviada por el solicitante (véase más abajo) a través del Patrocinador, este tipo de transacción pretende separar al pagador del gas del remitente de la transacción. | +| Solicitante | Se trata de un EOA (véase más abajo). El solicitante envía una transacción patrocinada al Patrocinador. No pagan el gas con criptomoneda nativa sino con un token aceptado por el Patrocinador, si no lo subvencionan. | +| Destinatario | Abreviatura de contrato de destinatario. Es el destino de la transacción del solicitante. | +| Sobre | Utilizando la analogía de los "sobres", es la transacción, (financiada con criptomoneda nativa como gas) enviada por el Patrocinador a la blockchain, la que envuelve la carga útil de la transacción del solicitante (transacción patrocinada). | +| Relé RIF | Todo el sistema que permite la retransmisión de las transacciones patrocinadas. | +| DoS | Una denegación de servicio es una amenaza a la seguridad de la información cuyo objetivo es hacer que un servicio no esté disponible. | +| DeFi | Acrónimo de Decentralized Finance, es una novedosa forma de financiación basada en la tecnología blockchain. | +| EOA | Una cuenta de propiedad externa (EOA) es una cuenta gestionada con una clave, que es capaz de firmar y enviar transacciones, y pagar el coste por ello. | +| Tasa | Importe del token que se cobra por cada transacción retransmitida. | +| Modelo de reparto de ingresos | Una forma de retransmitir las transacciones para que las comisiones se repartan entre varios socios. | +| Honorarios Receptor | Es el Trabajador/Cobrador designado que recibirá las tasas | + +## Componentes de la cadena + +### Centro de relés + +El concentrador de retransmisión es el componente principal de la arquitectura de retransmisión RIF. Actúa como interfaz con el servidor de retransmisión y con toda la arquitectura de la cadena. Remite todas las transacciones a sus respectivos contratos al tiempo que comprueba la validez del trabajador que está procesando la transacción. + +También forma parte del proceso de registro de los Relay Workers junto con los Relay Managers. Además, el Centro de Retransmisión guarda el importe de la apuesta de cada Gestor de Retransmisión para garantizar el buen comportamiento de sus trabajadores. +La cuenta que apuesta por un Gestor de Retransmisión específico por primera vez se convierte en la propietaria de la apuesta, sólo esta cuenta puede hacer apuestas posteriores para este Gestor de Retransmisión específico. + +Cuando un Gestor de Retransmisiones desautoriza un Centro de Retransmisiones, significa que se desestablece de él, lo que también significa que ya no puede retransmitir a través de ese centro. Cualquier saldo que haya en el centro de retransmisión se envía al remitente original de la participación (el propietario). + +El desenganche tiene un retardo predefinido (en bloques). Con ello se pretende evitar que el gestor de retransmisiones se desancle antes de un corte que se iba a producir. + +### Billetera inteligente + +Es la "cuenta basada en el contrato" propiedad de la EOA del Solicitante. Antes de ejecutar cualquier transacción utilizando el monedero inteligente, es necesario desplegar el contrato de monedero inteligente. + +Los monederos inteligentes son contratos que verifican los datos transmitidos y posteriormente invocan al contrato receptor de la transacción. La creación de carteras inteligentes no tiene ningún coste de gas proporcionando la ventaja de que se pueden desplegar sólo cuando sea necesario. + +Es el componente que llama al contrato del Destinatario (es decir, la dirección `msg.sender` que verá el Destinatario). Durante la ejecución, el contrato verifica la solicitud de retransmisión y, si es válida, llama a la función del destinatario definida; en caso contrario, revierte la invocación. La verificación incluye la comprobación de que el propietario de la SmartWallet realizó la solicitud, el rechazo de cualquier solicitud con una firma no válida y la prevención de ataques de repetición utilizando un nonce. + +El "monedero inteligente" se diseñó para interactuar únicamente con el sistema de retransmisión RIF, por lo que cualquier saldo en moneda nacional se transferirá al propietario del "monedero inteligente" después de cada transacción. + +### Cartera inteligente Native Holder + +El `monedero inteligente titular nativo` es un `monedero inteligente` que fue diseñado para tener interacciones fuera del sistema RIF Relay. Esto significa que puede contener moneda nativa, como su nombre indica. + +El comportamiento del `monedero inteligente de titular nativo` es el mismo que el del `monedero inteligente` con la diferencia de que la moneda nativa no será transferida de vuelta al propietario después de cada transacción y puede disponer del uso de la moneda nativa. + +### Cartera inteligente personalizada + +La `cartera inteligente personalizada` es una `cartera inteligente` que fue diseñada para ejecutar lógica personalizada después de cada transacción. La lógica personalizada se crea en el momento del despliegue del contrato y se puede ejecutar en cada transacción. + +### Gestor de relés + +Un EOA que tiene un saldo apostado. Cualquier penalización realizada contra un Trabajador de relevo afecta a la apuesta del Gestor de relevo. Un trabajador de relevo sólo puede ser gestionado por un gestor de relevo. Un gestor de retransmisiones puede tener uno o varios trabajadores de retransmisión. Las responsabilidades del Gestor de Retransmisiones son: registrar el Servidor de Retransmisiones y añadir Trabajadores de Retransmisiones, ambos en el Hub de Retransmisiones. + +### Gestor de participaciones + +El Stake Manager soporta múltiples Relay Hubs, los stakers son los Relay Managers y pueden autorizar/desautorizar Relay Hubs específicos para poder penalizar a los managers si es necesario. La criptomoneda apostada se mantiene en el contrato StakeManager. + +La cuenta que apuesta por primera vez por un Gestor de Retransmisiones específico se convierte en la propietaria de la apuesta, y sólo esta cuenta puede realizar apuestas posteriores para este Gestor de Retransmisiones específico. + +Cuando un Gestor de Retransmisiones desautoriza un Centro de Retransmisiones, significa que se desestablece de él, lo que también significa que ya no puede retransmitir a través de ese centro. Cualquier saldo que haya en el Centro de Retransmisión se envía al remitente original de la participación (el propietario). Además, los saldos de los trabajadores se transfieren al propietario de la participación y, si está configurado, el saldo del gestor de retransmisión también se puede transferir al propietario de la participación. + +El desenganche tiene un retardo predefinido (en bloques). Con ello se pretende evitar que el gestor de retransmisiones se desasocie antes de un corte que se iba a producir. + +### Trabajador de relevo + +Un EOA que pertenece a un solo Gestor de Retransmisión. Dado que el Trabajador de Retransmisión es el remitente de la solicitud, es el que paga las tasas de gas de cada transacción. También **puede** cobrar las tasas en ERC20 que se cobran por retransmitir las transacciones. + +### Verificador de retransmisión y despliegue + +Contratos que autorizan una solicitud específica de retransmisión o despliegue (véase la sección [Solicitudes de retransmisión y despliegue](#solicitudes-de-transmisión-despliegue)). + +Se ofrecen dos ejemplos de aplicación: + +- **Verificador de relés**: El Verificador de Retransmisión tiene una lista de fichas que acepta. Cuando recibe una solicitud de retransmisión, comprueba la aceptación del token y el saldo del pagador para el token. +- **Verificador de despliegue**: Implementación utilizada en el proceso de despliegue de SmartWallet. Realiza las mismas comprobaciones del verificador de retransmisión, pero también se asegura de que el SmartWallet que se va a desplegar no existe ya. También comprueba que se proporciona una dirección de fábrica de proxy en la solicitud de retransmisión. + +### Colector + +El recaudador es un contrato inteligente opcional que se utiliza para la función de reparto de ingresos. Normalmente, las comisiones de retransmisión se pagan a la cuenta del trabajador que retransmite la transacción. + +Los contratos colectores están diseñados para retener los ingresos generados por las transacciones retransmitidas, de modo que en el futuro puedan ser entregados a los socios de acuerdo con la distribución de participaciones escrita en el contrato. Se inicializan con un token específico que retener, un conjunto de direcciones de socios (cada conjunto con su propia cuota de ingresos recaudados) más un propietario que puede modificar las cuotas o ejecutar la retirada y distribución de fondos. Las participaciones de cada socio se expresan en números enteros que representan un porcentaje y deben sumar exactamente 100. Se puede especificar cualquier número de socios. Se puede especificar cualquier número de socios. + +El propietario del contrato puede ser cualquier dirección, incluyendo pero no limitándose a un contrato multisig (ver [Gnosis Safe Contracts](https://github.com/gnosis/safe-contracts)). Utilizar una dirección multisig puede ser una buena idea si es necesario compartir la propiedad del contrato, de forma que decisiones como la distribución de las cuotas cobradas a los socios o la modificación de las cuotas de ingresos puedan tomarse de forma colectiva. También existe una función de transferencia de propiedad. + +Se puede desplegar cualquier número de contratos de recaudación y utilizarlos para compartir ingresos, siempre que sus direcciones se especifiquen en las solicitudes de retransmisión. La retirada de fondos de cualquier contrato de recaudación es completamente independiente del flujo de retransmisión de RIF y puede ejecutarse en cualquier momento arbitrario. + +Para obtener información sobre cómo implementar un contrato de recopilador (además de otros detalles técnicos), consulte [la sección del recopilador](/developers/integrate/rif-relay/deployment) del proceso de implementación. + +### Apoderados + +#### Plantilla + +Es la lógica que se ejecutaría en cada transacción. En este escenario concreto, es el contrato Smart Wallet. + +#### Fábrica de proxy + +Fábrica de Proxies a la SmartWallet. La fábrica de proxies se encarga de desplegar los contratos de smart wallets utilizando la plantilla, durante el despliegue ejecuta la inicialización desde cada smart wallet. + +#### Proxy + +El proxy sólo se implementa en la Cartera Inteligente Personalizada porque delega cada llamada a una dirección lógica de SmartWallet. Este proxy es el que se instanciará por SmartWallet, y recibirá la dirección de SmartWallet como Copia Maestra (MC). Así, cada llamada realizada a este proxy terminará ejecutando la lógica definida en la MC. + +Para la ejecución de la transacción (llamada `execute()`), la lógica MC realizará la verificación de la firma y el pago. A continuación, ejecutará la solicitud y, si se ha definido una lógica personalizada, le reenviará el flujo antes de regresar. + +Durante la inicialización del monedero inteligente personalizado se puede establecer una lógica personalizada (que afectaría al estado del proxy, por supuesto), el proceso de inicialización y el establecimiento de la lógica personalizada sólo se puede hacer durante el despliegue del monedero inteligente. + +### GSNEip712Biblioteca + +Se trata de una biblioteca auxiliar que convierte la solicitud de retransmisión en una llamada a una cartera inteligente o a una fábrica de proxy (en tal caso, la solicitud es una solicitud de despliegue). + +Encontrará documentación detallada [aquí](https://eips.ethereum.org/EIPS/eip-712). + +## Componentes fuera de la cadena + +### Servidor de retransmisión + +El servidor de retransmisión recibe transacciones patrocinadas a través de HTTP. + +El servidor sólo tiene una dirección de Relay Manager y al menos un Relay Worker, y apunta a un único Relay Hub. +Cuando el Servidor de Retransmisión recibe una solicitud de Retransmisión HTTP, crea un Sobre, envolviendo la transacción patrocinada, lo firma utilizando su cuenta de Trabajador de Retransmisión y luego lo envía al contrato del Hub de Retransmisión. + +El servidor es un demonio de servicio que funciona como un servicio HTTP. Se anuncia a sí mismo (a través del concentrador de retransmisión) y espera las peticiones de los clientes. + +El Servidor de Retransmisión dispone de mecanismos que intentan evitar que se agote el saldo de los trabajadores. El Relay Manager sigue enviando criptomoneda nativa a los trabajadores en función de un saldo mínimo específico. + +#### Iniciar flujo + +El diagrama de flujo de inicio representa el proceso que sigue el Servidor Relay para comenzar a recibir peticiones, aun que el servidor este recibiendo peticiones no significa que pueda manejarlas, ya que necesita balance para procesar cada petición. +Relay - Flujo de Inicio](/img/rif-relay/start.jpg) + +1. Genera (claves privadas) las cuentas de los Trabajadores y del Gestor. +2. Inicializa la instancia para cada contrato que vaya a interactuar con el servidor. + +- El contrato RelayHub es el contrato clave para el flujo de inicio, ya que es el contrato que tiene los eventos de interés. + +3. Initalizar el Servidor de Retransmisión. + -El Servidor de Retransmisión tiene toda la lógica para la interacción entre los componentes fuera de la cadena y dentro de la cadena. +4. Inicializar el RegistationManager. + +- El Gestor de Registro empieza a buscar eventos relacionados con el proceso de registro (StakeAdded, WorkerAdded) para identificar si se puede registrar el Servidor en el RelayHub. + +5. El servidor de retransmisión empieza a buscar cambios en la cadena de bloques mediante RelayHub. + +#### Flujo de registros + +El diagrama de flujo de registro representa el proceso para proporcionar el stake/balance necesario al gestor/trabajadores para que el Servidor de Retransmisión empiece a procesar peticiones y para registrar el servidor en el RelayHub. + +Relé - Flujo de registro](/img/rif-relay/register.jpg) + +1. Obtiene los datos del Servidor de Retransmisión. +2. Valida si el servidor ya estaba registrado en el RelayHub. +3. Inicializa la instancia para cada contrato que vaya a interactuar con el servidor. + +- El contrato RelayHub es el contrato clave para el flujo de registro ya que es el contrato que tiene los eventos de interés. + +4. Consulta el stakeInfo del gestor y valida si ya está apostado. +5. Financie al gestor si es necesario. + +### Controlador de intervalos + +El diagrama del manejador de intervalos representa el proceso del Servidor de retransmisión para interactuar con la cadena de bloques y procesar las transacciones. + +Relé - Flujo del controlador de intervalos](/img/rif-relay/interval-handler.jpg) + +1. Obtenga el último bloque minado por la cadena de bloques. +2. Comprueba si es necesario actualizar el estado del Servidor de retransmisión en función de los bloques acuñados. +3. Refresca el precio de la gasolina. +4. Obtén los eventos pasados del RelayHub. +5. Añade los trabajadores y registra el Servidor de Retransmisión si cumple los requisitos. +6. Siga atento a las transacciones y a los nuevos acontecimientos. + +### Solicitudes de retransmisión y despliegue + +Una solicitud de retransmisión es la transacción patrocinada, la estructura utilizada para retransmitir una transacción. Está formada por Relay Data y Forward Request: + +- **Datos de retransmisión**: Toda la información necesaria para retransmitir la solicitud de reenvío definida. +- **Solicitud de reenvío/despliegue**: Está formada por todos los campos "comunes" de la transacción además de todos los datos del token-pago. + +Cuando el patrocinador crea un sobre (la transacción real de blockchain que se va a enviar), añadirá esta solicitud de retransmisión (transacción patrocinada) como parte de los datos codificados, junto con el contrato y el método a llamar (RelayHub y relayCall respectivamente). + +La **Solicitud de retransmisión** es una estructura que envuelve la transacción enviada por un usuario final. Incluye los datos necesarios para retransmitir la transacción, como la dirección del pagador, la dirección del solicitante original y los datos del pago simbólico. + +La estructura **Deploy request** que envuelve la transacción enviada para desplegar un monedero inteligente. + +### Herramientas + +### Cliente de retransmisión + +Se trata de una biblioteca typescript para interactuar con el sistema de relés RIF. Proporciona APIs para encontrar un relé, y para enviar transacciones a través de él. También expone métodos para interactuar con la cadena de bloques. + +Puede funcionar como punto de acceso al sistema de retransmisión. Crea, firma y envía la transacción patrocinada, que es firmada por el solicitante y reenviada al servidor de retransmisión mediante el protocolo HTTP. + +No es _estrictamente_ necesario ya que cualquier dApp o usuario podría retransmitir transacciones utilizando simplemente un Servidor de Retransmisión y los contratos inteligentes, aunque esto es posiblemente más difícil de hacer manualmente. + +### Proveedor de retransmisión + +Es el punto de acceso al sistema RIF Relay. Envuelve el `Relay Client` para la compatibilidad con el proveedor Ethers.js. + +## Flujo de ejecución + +### Retransmisión (Cartera inteligente ya desplegada) + +Relé - Flujo de ejecución](/img/rif-relay/execution.jpg) + +1. Un solicitante crea una petición. +2. Un Solicitante envía la solicitud al Cliente de Retransmisión (a través de un Proveedor de Retransmisión). +3. El cliente de retransmisión envuelve la solicitud en una solicitud de retransmisión y la firma. +4. El Cliente de Retransmisión envía la Solicitud de Retransmisión al Servidor de Retransmisión (a través de Cliente HTTP ↔ Servidor HTTP). +5. El Servidor de Retransmisión crea una transacción que incluye la Solicitud de Retransmisión y la firma con una cuenta de Trabajador de Retransmisión. +6. La cuenta Relay Worker es un EOA registrado en el Relay Hub. +7. El Servidor de Retransmisión envía la transacción al Centro de Retransmisión utilizando la misma cuenta de trabajador que en el paso anterior, ejecutando la función `relayCall` del contrato del Centro de Retransmisión. + - Cuando el Centro de Retransmisión recibe una transacción de un Trabajador de Retransmisión, verifica con el Gestor de Participaciones que el Gestor de Retransmisiones del Trabajador ha bloqueado los fondos para la participación. Si no es así, se revierte la ejecución. + - La cuenta del relevista debe tener fondos para pagar el gas consumido (RBTC). + - Esta verificación se realiza en el cliente de retransmisión y también en el servidor de retransmisión, llamando al verificador de retransmisión. El verificador comprueba que acepta el token utilizado para pagar y que el pagador tiene un saldo de tokens suficiente. Además, verifica que el monedero inteligente utilizado es el correcto. +8. El RelayHub indica a la Cartera Inteligente que ejecute la Solicitud de Retransmisión a través de la biblioteca [GsnEip712Library](#gsneip712library). +9. La Cartera Inteligente comprueba la firma y el nonce del Solicitante, revirtiendo si falla las comprobaciones. +10. A continuación, la cartera inteligente realiza la transferencia de tokens entre el solicitante y el destinatario de tokens, utilizando los datos recibidos en la solicitud de retransmisión. +11. Invoca el contrato del destinatario con el método indicado en la solicitud de reenvío. + +### Despliegue patrocinado de la cartera inteligente + +Relay - Billetera inteligente patrocinada](/img/rif-relay/relay.jpg) + +El solicitante sin gas tiene una dirección SmartWallet donde recibe los tokens pero no los utiliza. Si el solicitante necesita llamar a un contrato, por ejemplo, para enviar los tokens a otra cuenta, debe desplegar primero una Smart Wallet. + +1. Un solicitante crea una solicitud de despliegue de cartera. +2. Un Solicitante envía la solicitud al Servidor de Retransmisión a través del Cliente de Retransmisión. +3. El Cliente de Retransmisión envuelve la transacción enviada por el Solicitante en una Solicitud de Despliegue para crear la Cartera Inteligente y la firma. +4. El Cliente de Retransmisión envía al Servidor de Retransmisión una Solicitud de Despliegue (a través de Cliente HTTP ↔ Servidor HTTP). +5. El servidor de retransmisión firma la transacción que contiene la solicitud de despliegue con la cuenta del trabajador de retransmisión. +6. El Servidor de Retransmisión envía la solicitud al Centro de Retransmisión utilizando la cuenta del Trabajador de Retransmisión que ejecuta la función `relayCall` del contrato del Centro de Retransmisión. + +- Aquí es donde el Servidor de Retransmisión normalmente llamará al Verificador de Despliegue para asegurarse: + - El Verificador acepta las fichas ofrecidas. + - El verificador conoce la instancia de fábrica de proxy que debe utilizarse. + - El contrato Proxy Factory no está creando una Cartera Inteligente existente. + - El solicitante tiene suficientes fichas para pagar. + +7. El Relay Hub llama a la Proxy Factory utilizando el método `relayedUserSmartWalletCreation`. +8. La fábrica de proxy realiza las siguientes comprobaciones: + - Comprueba el nonce del remitente. + - Comprueba la firma de la solicitud de despliegue. +9. La Fábrica de Proxy crea la Cartera Inteligente utilizando el opcode `create2`. +10. A continuación, llama a la función `initialize` del contrato Smart Wallet. + - La Cartera Inteligente, durante su inicialización, ejecuta la transferencia de tokens. + - A continuación, inicializa el estado de la Cartera Inteligente y establece el EOA del solicitante como propietario de la Cartera Inteligente. + - En el caso de que exista una lógica personalizada, también se llama a su inicialización. + +## Obsoleto + +### Pagador + +La versión 0.2 eliminó los contratos Paymaster en favor de los Verificadores (véase [versions](/developers/integrate/rif-relay/versions/)). diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/contracts.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/contracts.md new file mode 100644 index 00000000..7dea556a --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/contracts.md @@ -0,0 +1,135 @@ +--- +sidebar_label: Contratos +sidebar_position: 700 +title: RIF Relay - Contratos +tags: + - rif + - sobre + - relé + - integrar +description: Contratos de relevo RIF +--- + +## Mainnet + +### Versión 1 + +#### Contratos primarios\*\* + +``` +| Contrato | Dirección | +|--------------------|--------------------------------------------| +| Penalizador | 0x4fd591b8330d352c57CA1CC1dA172dCa516722E3 | +| RelayHub | 0x438Ce7f1FEC910588Be0fa0fAcD27D82De1DE0bC | +| SmartWallet | 0x59C40304E8a428BF1D17f03a6aE84B635964DB19 | +| SmartWalletFactory | 0x9EEbEC6C5157bEE13b451b1dfE1eE2cB40846323 | +| DeployVerifier | 0x2FD633E358bc50Ccf6bf926D621E8612B55264C9 | +| RelayVerifier | 0x5C9c7d96E6C59E55dA4dCf7F791AE58dAF8DBc86 | +``` + +#### Para soporte de CustomSmartWallet + +``` +| Contrato | Dirección | +|---------------------------------|--------------------------------------------| +| CustomSmartWallet | 0x4b2464E8d062633D18ba0928c064037Da415eD1f | +| CustomSmartWalletFactory | 0x0002E79883280C1717e41EE5D3705D55960B5bAe | +| CustomSmartWalletDeployVerifier | 0x5910868059431026ACa58a73124DedbEF4cb97db | +| CustomSmartWalletRelayVerifier | 0xb6eFDB335b4D52705e9973069500fd79410BEC01 | +``` + +#### Para pruebas + +``` +| Contract | Address | +|-------------------|--------------------------------------------| +| SampleRecipient | 0x479eA66AAEfC00EdC1590c9da07152def9452cf9 | +| TestToken | 0xe49b8906A3ceFd184621A4193e2451b1c3C3dB0B | +``` + +## Testnet + +### Versión 1 + +#### Contratos primarios + +``` +| Contrato | Dirección | +|--------------------|--------------------------------------------| +| Penalizador | 0x8e67406bD3A926b43Fda158C673230B77f874CDd | +| RelayHub | 0xAd525463961399793f8716b0D85133ff7503a7C2 | +| SmartWallet | 0x86bD3006B757614D17786428ADf3B442b2722f59 | +SmartWalletFactory 0xCBc3BC24da96Ef5606d3801E13E1DC6E98C5c877 +DeployVerifier 0xc67f193Bb1D64F13FD49E2da6586a2F417e56b16 +RelayVerifier 0xB86c972Ff212838C4c396199B27a0DBe45560df8 +``` + +#### Para soporte de CustomSmartWallet + +``` +| Contrato | Dirección | +|---------------------------------|--------------------------------------------| +| CustomSmartWallet | 0x2c66922D704999Ff9F378838172fe5c5e0Ac2d27 | +| CustomSmartWalletFactory | 0x91C186Dcb11EcBf234c778D7779e8e10f8ADD1a8 | +CustomSmartWalletDeployVerifier 0x87421afb27FC680D99E82Bce8Df140E81F5c11a3 +CustomSmartWalletRelayVerifier 0x6e23B72723886b066a5C26Baa2b2AfB0b1d51e5c +``` + +#### Para pruebas + +``` +Contrato | Dirección | +|-------------------|--------------------------------------------| +| SampleRecipient | 0xc4B8B6C02EC34d84630Ba8C684954a0A04C656FC | +| TestToken | 0x3F49BaB0afdC36E9f5784da91b32E3D5156fAa5C | 0x3F49BaB0afdC36E9f5784da91b32E3D5156fAa5C | Contrato | Dirección | +``` + +### Versión 0.2 + +#### Contratos primarios + +``` +| Contrato | Dirección | +|--------------------|--------------------------------------------| +| Penalizador | 0x5FdeE07Fa5Fed81bd82e3C067e322B44589362d9 | +| RelayHub | 0xe90592939fE8bb6017A8a533264a5894B41aF7d5 | +| SmartWallet | 0x27646c85F9Ad2559897DB0d99bC4a9DF2EdA68 | +| SmartWalletFactory | 0xEbb8AA43CA09fD39FC712eb57F47A9534F251996 | +| DeployVerifier | 0x345799D90aF318fd2d8CbA87cAD4894feF2f3518 | +| RelayVerifier | 0xDe988dB9a901C29A9f04050eB7ab08f71868a8fc | +``` + +#### Para soporte de CustomSmartWallet + +``` +| Contrato | Dirección | +|---------------------------------|--------------------------------------------| +| CustomSmartWallet | 0xB8dB52615B1a94a03C2251fD417cA4d9454530 | +| CustomSmartWalletFactory | 0xA756bD95D8647be254de40B842297c945D8bB9a5 | +CustomSmartWalletDeployVerifier 0x3c26685CE3ac89F755D68A81175655b4bBE54AE0 +CustomSmartWalletRelayVerifier 0xBcCA9B8faA9cee911849bFF83B869d230f83f945 +``` + +### Para pruebas + +``` +| Contrato | Dirección | +|-------------------|--------------------------------------------| +| SampleRecipient | 0x4De3eB249409e8E40a99e3264a379BCfa10634F5 | +| TestToken | 0x77740cE4d7897430E74D5E06540A9Eac2C2Dee70 | Contrato | Dirección | ------------------- +``` + +#### Versión 0.1 + +``` +| Contrato | Dirección | +|----------------|--------------------------------------------| +| StakeManager | 0x4aD91a4315b3C060F60B69Fd0d1eBaf16c14148D | +| Penalizador | 0xd3021763366708d5FD07bD3A7Cd04F94Fc5e1726 | +RelayHub 0x3f8e67A0aCc07ff2F4f46dcF173C652765a9CA6C +TestRecipient 0xFBE5bF13F7533F00dF301e752b41c96965c10Bfa | +| SmartWallet | 0xE7552f1FF31670aa36b08c17e3F1F582Af6302d1 | +| ProxyFactory | 0xb7a5370F126d51138d60e20E3F332c81f1507Ce2 | +DeployVerifier 0x3AD4EDEc75570c3B03620f84d37EF7F9021665bC +RelayVerifier 0x053b4a77e9d5895920cBF505eB8108F99d929395 +``` diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/deployment.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/deployment.md new file mode 100644 index 00000000..17da14ae --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/deployment.md @@ -0,0 +1,371 @@ +--- +sidebar_label: Despliegue del repetidor RIF +sidebar_position: 500 +title: Despliegue del repetidor RIF +tags: + - rif + - sobre + - relé + - guía de integración +description: Proceso de despliegue del relé RIF +--- + +## Configurar los contratos de retransmisión RIF y el servidor + +### Despliegue de contratos + +Empiece por desplegar componentes en la cadena. Todas las herramientas necesarias se encuentran en el [repositorio de contratos de retransmisión RIF](https://github.com/rsksmart/rif-relay-contracts) + +#### Regtest + +1. Clonar el repositorio: + +```bash + git clone https://github.com/rsksmart/rif-relay-contracts +``` + +2. Navegue hasta el directorio e instale las dependencias: + +```bash + cd rif-relay-contracts + npm install +``` + +3. Despliega el contrato: + +```bash + npx hardhat deploy --network regtest +``` + +> Esto utiliza la configuración Regtest de `hardhat.config.ts`. + +Tras el despliegue, verá un resumen de los contratos desplegados. Este resumen incluye los componentes en cadena esenciales para RIF Relay, y contratos adicionales con fines de prueba y validación.````texto + ┌───────────────────────────────────────┬──────────────────────────────────────────────┐ + │ (índice) │ Valores │ + ├───────────────────────────────────────┼──────────────────────────────────────────────┤ + │ Penalizador │ '0x77045E71a7A2c50903d88e564cD72fab11e82051' │ + │ RelayHub │ '0xDA7Ce79725418F4F6E13Bf5F520C89Cec5f6A974' │ + │ SmartWallet │ '0x83C5541A6c8D2dBAD642f385d8d06Ca9B6C731ee' │ + │ SmartWalletFactory │ '0xE0825f57Dd05Ef62FF731c27222A86E104CC4Cad' │ + │ DeployVerifier │ '0x73ec81da0C72DD112e06c09A6ec03B5544d26F05' │ + │ RelayVerifier │ '0x03F23ae1917722d5A27a2Ea0Bcc98725a2a2a49a' │ + │ CustomSmartWallet │ '0x1eD614cd3443EFd9c70F04b6d777aed947A4b0c4' │ + │ CustomSmartWalletFactory │ '0x5159345aaB821172e795d56274D0f5FDFdC6aBD9' │ + │ CustomSmartWalletDeployVerifier │ '0x7557fcE0BbFAe81a9508FF469D481f2c72a8B5f3' │ + │ CustomSmartWalletRelayVerifier │ '0x0e19674ebc2c2B6Df3e7a1417c49b50235c61924' │ + │ NativeHolderSmartWallet │ '0x4aC9422c7720eF71Cb219B006aB363Ab54BB4183' │ + │ NativeHolderSmartWalletFactory │ '0xBaDb31cAf5B95edd785446B76219b60fB1f07233' │ + │ NativeHolderSmartWalletDeployVerifier │ '0xAe59e767768c6c25d64619Ee1c498Fd7D83e3c24' │ + │ NativeHolderSmartWalletRelayVerifier │ '0x5897E84216220663F306676458Afc7bf2A6A3C52' │ + │ UtilToken │ '0x1Af2844A588759D0DE58abD568ADD96BB8B3B6D8' │ + │ VersionRegistry │ '0x8901a2Bbf639bFD21A97004BA4D7aE2BD00B8DA8' │ + └───────────────────────────────────────┴──────────────────────────────────────────────┘ + ``` +El resumen de despliegue muestra dos conjuntos de Carteras Inteligentes, cada uno emparejado con sus verificadores. Esto se debe a que el verificador se utiliza tanto para el despliegue como para la validación de transacciones. Para las pruebas, nos centraremos en el uso de estos Contratos de Cartera Inteligente. +```` + +#### Testnet + +1. Asegúrate de que tu cuenta tiene fondos. Puede obtener fondos de [tRBTC Faucet](https://faucet.rootstock.io/). +2. Despliegue en Testnet: + ```bash + npx hardhat deploy --network testnet + ``` + +> Recuerde configurar Testnet en `hardhat.config.ts`. Los contratos existentes de RIF Relay desplegados en Testnet se pueden encontrar en la sección [contracts](/developers/integrate/rif-relay/contracts). + +#### Mainnet + +1. Asegúrese de que su cuenta tiene fondos. +2. Despliegue en Mainnet: + ```bash + npx hardhat deploy --network mainnet + ``` + +> Asegúrese de que Mainnet está configurado en `hardhat.config.ts`. Los contratos existentes de RIF Relay desplegados en Mainnet se pueden encontrar en la [sección de contratos](/developers/integrate/rif-relay/contracts). + +### Reparto de ingresos + +La distribución de ingresos es una función opcional de RIF Relay que puede implementarse mediante contratos de recopilador. Puede implementar varios contratos de recopilador, pero no se incluyen en la implementación predeterminada de contratos de Relay. Para obtener información detallada sobre los contratos de recopilador, consulte la [documentación de arquitectura](/developers/integrate/rif-relay/architecture#collector). + +Antes de desplegar un contrato de recopilador, asegúrese de lo siguiente: + +1. Asegúrese de que el token elegido para el contrato de recaudación es el mismo que el utilizado para las comisiones de transacción. + > **Nota:** No puede recuperar otros tokens que no sean los establecidos durante la implementación del recopilador. +2. Seleccione un propietario adecuado para el contrato de recaudación. Este propietario no tiene por qué ser el implementador, pero debe tener autoridad para ejecutar la función de retirada, o de lo contrario los fondos de ingresos quedarán bloqueados en el contrato. +3. Configure los socios y sus porcentajes de participación, asegurándose de que el total sume 100%. Los tokens enviados incorrectamente a una dirección inaccesible sin una clave privada del beneficiario se perderán. Para ver un ejemplo de definición de participaciones en ingresos estructuralmente válida, consulte [configuración de ejemplo](https://github.com/rsksmart/rif-relay-contracts/blob/master/deploy-collector.input.sample.json). + +#### Regtest + +Para desplegar el contrato del colector, utilizaremos el [Contrato de retransmisión RIF](https://github.com/rsksmart/). + +1. Cree un archivo de configuración llamado `deploy-collector.input.json` con la estructura requerida: + ````json + { + "colectorPropietario": "0xCD2a3d9F938E13CD947Ec05AbC7FE734Df8DD826", + "partners": [ + { + "beneficiario": "0x7986b3DF570230288501EEa3D890bd66948C9B79", + "cuota": 20 + }, + { + "beneficiario": "0x0a3aA774752ec2042c46548456c094A76C7F3a79", + "share": 35 + }, + { + "beneficiario": "0xCF7CDBb5F7BA79d3ffe74A0bBA13FC0295F6036", + "share": 13 + }, + { + "beneficiario": "0x39B12C05E8503356E3a7DF0B7B33efA4c054C409", + "share": 32 + } + ], + "tokenAddresses": ["0x1Af2844A588759D0DE58abD568ADD96BB8B3B6D8"], + "remainderAddress": "0xc354D97642FAa06781b76Ffb6786f72cd7746C97" + } + ``` + + ```` + +> **Nota:** Las cuentas `collectorOwner`, `beneficiaries` y `remainderAddress` son las cinco primeras cuentas proporcionadas por el nodo en Regtest. + +2. Despliega el contrato: + ```bash + npx hardhat collector:deploy --network regtest + ``` + +El cobrador está listo y puede empezar a recibir comisiones. + +#### Testnet + +Utilizando el archivo de configuración que creó en la sección regtest, ejecute este comando para desplegar el contrato: + +```js + npx hardhat collector:deploy --network testnet +``` + +#### Mainnet + +Utilizando el archivo de configuración que creó en la sección regtest, ejecute este comando para desplegar el contrato: + +```js + npx hardhat collector:deploy --network mainnet +``` + +### Permitir fichas + +RIF Relay sólo acepta tokens de la lista blanca, principalmente para garantizar que sólo se aceptan tokens de valor para el operador. Para incluir un token en la lista blanca +Ejecute la función `acceptToken(address token)` en los contratos de los verificadores de Relay, que incluyen: + +- `SmartWalletDeployVerifier` +- `SmartWalletRelayVerifier` + +:::info[Note] +Esta acción debe ser realizada por el propietario de los contratos, normalmente la cuenta que realizó el despliegue. +::: + +#### Regtest + +En los Contratos de Relé RIF, ejecute este comando: + +```js + npx hardhat allow-tokens --network regtest --token-list +``` + +> `` es una lista separada por comas de las direcciones de los tokens que se permitirán en los verificadores disponibles. El `allowTokens` utiliza la primera cuenta (referida como account[0]) como propietaria de los contratos. Esto es importante porque sólo el propietario de la cuenta puede permitir tokens. + +#### Testnet + +En los Contratos de relevo RIF, ejecute el comando: + +```js + npx hardhat allow-tokens --network testnet --token-list +``` + +> \ es una lista separada por comas de las direcciones de tokens que se permitirán en los verificadores disponibles. El script `allowTokens` utilizará la red Testnet configurada en el `hardhat.config.ts`, esta red deberá utilizar la cuenta que desplegó los contratos. +> También puedes modificar los tokens permitidos para verificadores específicos usando la opción `--verifier-list` de la siguiente manera: + +```js + npx hardhat allow-tokens --network testnet --token-list --verifier-list +``` + +> El ``, `` es una lista separada por comas de direcciones de verificadores para permitir los tokens. + +#### Mainnet + +En los Contratos de relevo RIF, ejecute el comando: + +```js + npx hardhat allow-tokens --network mainnet --token-list +``` + +> \ es una lista separada por comas de las direcciones de tokens que se permitirán en los verificadores disponibles. El script `allowTokens` utilizará la red Mainnet configurada en `hardhat.config.ts`, esta red deberá utilizar la cuenta que realizó el despliegue de los contratos. +> También puedes modificar los tokens permitidos sólo para verificadores específicos usando la opción `--verifier-list` de la siguiente manera: + +```js + npx hardhat allow-tokens --network testnet --token-list --verifier-list +``` + +> El ``, `` es una lista separada por comas de direcciones de verificadores para permitir los tokens. + +:::info[Note] +El nombre de la red; regtest, testnet, o mainnet, es un parámetro opcional que se toma del archivo hardhat.config.ts. El nombre de red que especifiques debe ser el mismo que el utilizado para desplegar el contrato. +::: + +### Ejecutar el servidor de retransmisión RIF + +Tras configurar los componentes dentro de la cadena, el siguiente paso es configurar los componentes fuera de la cadena, utilizando el [RIF Relay Server](https://github.com/rsksmart/rif-relay-server). +La configuración del Servidor de Retransmisión se simplifica utilizando el paquete [node-config](https://www.npmjs.com/package/config). Para conocer las ventajas detalladas de este paquete, visita su [wiki](https://github.com/node-config/node-config/wiki). + +El TL;DR: En el directorio `config`, cree un archivo llamado `local.json`. +Para obtener información visual sobre cómo funciona el Servidor de Retransmisión, consulte los diagramas disponibles [aquí](/developers/integrate/rif-relay/architecture/). + +#### Regtest + +A continuación se muestra un ejemplo de configuración para configurar el nodo RSKj localmente con los contratos desplegados en Regtest: + +```json +{ + "app": { + "url": "http://127.0.0.1", + "port": 8090, + "devMode": true, + "logLevel": 1, + "workdir": "./enveloping/environment/", + }, + "blockchain": { + "rskNodeUrl": "http://127.0.0.1:4444", + }, + "contracts": { + "relayHubAddress": "0xDA7Ce79725418F4F6E13Bf5F520C89Cec5f6A974", + "relayVerifierAddress": "0x03F23ae1917722d5A27a2Ea0Bcc98725a2a2a49a", + "deployVerifierAddress": "0x73ec81da0C72DD112e06c09A6ec03B5544d26F05" + } +} +``` + +> **Nota:** Los verificadores de retransmisión y despliegue utilizan los contratos de la sección Cartera inteligente del resumen. + +El significado de cada clave puede consultarse en [Configuración del servidor de retransmisión RIF](https://github.com/rsksmart/rif-relay-server#server-configuration) + +Para iniciar el servidor, ejecute el siguiente comando: + +```js + npm run start +``` + +> Por defecto, el servidor utiliza el fichero `default.json5` del directorio config. Dependiendo del perfil en `NODE_ENV`, los valores en el archivo `default.json5` se anulan. + +En este punto el servidor debería estar funcionando y listo para empezar a procesar transacciones, sin embargo, todavía necesitas registrar los componentes fuera de la cadena en el Relay Hub. + +Para habilitar el servidor para el procesamiento de transacciones, debe registrar los componentes fuera de la cadena en el Centro de retransmisión. Este paso requiere que el servidor esté activo. Para registrar los componentes, en una ventana de terminal diferente, ejecute el siguiente comando: + +```js + npm ejecutar registro +``` + +El proceso de registro realiza las siguientes acciones: + +- Estaca el gestor de relevo +- Añade el Relay Worker +- Registra el Servidor de Retransmisión + +El servidor ya está listo para empezar a procesar transacciones y se muestra un mensaje de "listo" en la consola. Para más detalles sobre los parámetros de configuración y registro, consulte la [Documentación del servidor de retransmisión RIF](https://github.com/rsksmart/rif-relay-server#overrides). + +#### Testnet + +A continuación se muestra un archivo de configuración de ejemplo que utiliza los componentes fuera de cadena desplegados en la red de pruebas Rootstock (https://rpc.testnet.rootstock.io/{YOUR_APIKEY}). + +> **Importante:** Debido a módulos específicos habilitados en los nodos RSKj, el Servidor de Retransmisión RIF no puede conectarse a los nodos públicos. + +```json + { + "app": { + "url": "https://backend.dev.relay.rifcomputing.net", + "port": 8090, + "devMode": true, + "logLevel": 1, + "feePercentage": "0", + "workdir": "/srv/app/environment" + }, + "blockchain": { + "rskNodeUrl": "http://172.17.0.1:4444" + }, + "contracts": { + "relayHubAddress": "0xAd525463961399793f8716b0D85133ff7503a7C2", + "relayVerifierAddress": "0xB86c972Ff212838C4c396199B27a0DBe45560df8", + "deployVerifierAddress": "0xc67f193Bb1D64F13FD49E2da6586a2F417e56b16" + } + } +``` + +> Los [contratos](/developers/integrate/rif-relay/contracts/) utilizados en esta configuración son los contratos primarios disponibles en la red Rootstock. Estos contratos primarios, sin embargo, no incluyen soporte para la `CustomSmartWallet`. + +Para obtener información detallada sobre cada clave de configuración utilizada para configurar el servidor de retransmisión RIF, consulte la documentación [Configuración del servidor de retransmisión RIF](https://github.com/rsksmart/rif-relay-server#server-configuration). + +Para iniciar el servidor, ejecute el siguiente comando: + +```js + npm run start +``` + +> Por defecto, el servidor utiliza el fichero `default.json5` del directorio config. Dependiendo del perfil en `NODE_ENV`, los valores en el archivo `default.json5` son anulados. Por lo tanto, es necesario configurar el entorno `NODE_ENV` a `testnet`. + +En este punto, el servidor debería estar funcionando y listo para empezar a procesar transacciones; sin embargo, aún necesitas registrar los componentes fuera de la cadena en el Relay Hub. Para el proceso de registro, el Relay Manager y el Worker deben tener fondos. + +Para obtener las direcciones, es necesario que el servidor esté activo. En una ventana de terminal diferente, ejecute el siguiente comando: + +```bash + curl http:///cadena-info +``` + +```json +{ + "relayWorkerAddress": "0xabf898bd73b746298462915ca91623f5630f2462", + "relayManagerAddress": "0xa71d65cbe28689e9358407f87e0b4481161c7e57", + "relayHubAddress": "0xe90592939fE8bb6017A8a533264a5894B41aF7d5", + "feesReceiver": "0x52D107bB12d83EbCBFb4A6Ad0ec866Bb69FdB5Db", + "minGasPrice": "6000000000", + "chainId": "31", + "networkId": "31", + "ready": false, + "version": "2.0.1" +} +``` + +1. Envía una cantidad arbitraria de tRBTC, 0,001 tRBTC por ejemplo, al Trabajador y al Gestor. +2. Ahora ejecuta el comando de registro. + +```js + npm ejecutar registro +``` + +He aquí un ejemplo de `register.json5`. + +```json + { + "registro": { + "stake": "REGISTER_STAKE", + "funds": "REGISTER_FUNDS", + "mnemonic": "REGISTER_MNEMONIC", + "privateKey": "REGISTER_PRIVATE_KEY", + "hub": "REGISTER_HUB_ADDRESS", + "gasPrice": "REGISTER_GAS_PRICE", + "relayUrl": "REGISTER_RELAY_URL", + "unstakeDelay": "REGISTER_UNSTAKE_DELAY" + } + } +``` + +El proceso de registro realiza las siguientes acciones: + +- Estaca el gestor de relevo +- Añade el Relay Worker +- Registra el Servidor de Retransmisión + +El servidor ya está listo para empezar a procesar transacciones y se muestra un mensaje de listo en la consola. Para más detalles sobre la configuración y los parámetros de registro, consulte la [Documentación del servidor de retransmisión RIF](https://github.com/rsksmart/rif-relay-server#overrides). + +#### Mainnet + +- Para ejecutar el servidor de retransmisión de RIF en la red principal de Rootstock, el procedimiento es el mismo que en la red de prueba, la única diferencia es la configuración. Configúrelo para utilizar contratos desplegados en Mainnet y un nodo RSKj conectado a Mainnet. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/develop.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/develop.md new file mode 100644 index 00000000..124243e5 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/develop.md @@ -0,0 +1,30 @@ +--- +sidebar_label: Desarrollar +sidebar_position: 600 +title: RIF Relé Desarrollar +tags: + - rif + - sobre + - relé + - usuario + - guía +description: Proceso de despliegue del relé RIF +--- + +## Inicializar el proyecto + +Para utilizar RIF Relay, siga estos pasos para construir el proyecto. + +## Estructura del proyecto + +El proyecto está dividido en varios módulos que interactúan entre sí. +Cada proyecto tiene su propia documentación en su repositorio. + +1. [Contratos de relevo RIF](https://github.com/rsksmart/rif-relay-contracts) +2. [Cliente de retransmisión RIF](https://github.com/rsksmart/rif-relay-client) +3. [Servidor de retransmisión RIF](https://github.com/rsksmart/rif-relay-server) +4. [RIF Relay Sample dApp](https://github.com/rsksmart/rif-relay-sample-dapp) + +## Comprometiendo cambios + +Para contribuir al proyecto, crea una rama con el nombre de la nueva funcionalidad que estás implementando (por ejemplo, `gas-optimization`). Cuando envías un commit a git, se ejecuta un hook. El gancho ejecuta un linter y todas las pruebas. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/gas-costs.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/gas-costs.md new file mode 100644 index 00000000..95830f0c --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/gas-costs.md @@ -0,0 +1,33 @@ +--- +sidebar_label: Costes del gas +sidebar_position: 950 +title: Relé RIF - Gastos de gas +tags: + - rif + - sobre + - relé + - integrar +description: Costes de gas del relé RIF +--- + +El coste adicional del gas es la cantidad extra de gas necesaria para procesar la llamada de retransmisión solicitada por el usuario. Llamemos **X** al gas consumido por la llamada al método del contrato de destino, y **Y** al gas total consumido por la llamada de retransmisión, entonces el coste de la llamada de retransmisión (es decir, el coste del gas de sobrecarga) es: **Z = Y - X**. + +## Plantillas SmartWallet + +RIF Relay V0.1 sólo tiene una [plantilla] SmartWallet (https://github.com/rsksmart/rif-relay/blob/master/contracts/smartwallet/SmartWallet.sol), que se puede utilizar tal cual o inyectarle lógica adicional durante la creación de la instancia SmartWallet. + +V0.2 introduce una plantilla más barata ([SmartWallet](https://github.com/rsksmart/rif-relay/blob/master/contracts/smartwallet/SmartWallet.sol)), para ser utilizada cuando no hay necesidad de lógica personalizada extra en las carteras inteligentes. El comportamiento es el mismo que el de la [plantilla] CustomSmartWallet(https://github.com/rsksmart/rif-relay/blob/master/contracts/smartwallet/SmartWallet.sol) de la V0.2, pero sin esta capacidad. + +### Coste de gas del despliegue de cada plantilla. + +| Versión RIF | Plantilla SW | Gas general medio | +| ------------------- | --------------------------------- | ----------------- | +| 0.1 | SmartWallet | 172400 | +| 0.2 | Cartera inteligente personalizada | 98070 | +| 0.2 | SmartWallet | 97695 | +| 1 | CustomSmartWallet | TBD | +| 1 | SmartWallet | TBD | + +:::tip[Note] +La instancia de CustomSmartWallet utilizada no apuntaba a ninguna lógica personalizada adicional. +::: diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/installation-requirements.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/installation-requirements.md new file mode 100644 index 00000000..864af93e --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/installation-requirements.md @@ -0,0 +1,54 @@ +--- +sidebar_label: Configurar +sidebar_position: 300 +title: Requisitos de instalación del relé RIF +tags: + - rif + - sobre + - relé + - usuario + - guía +description: Requisitos para instalar el relé RIF +--- + +Para configurar el sistema RIF Relay funcionando localmente se necesitan algunas herramientas. Todas estas herramientas son de código abierto y tienen su propia página de soporte. La funcionalidad de RIF Relay no depende de estas tecnologías y podría actualizarse o sustituirse, si fuera necesario. + +## Requisitos de hardware + +``` +- **Un ordenador con arquitectura x86_64 o Apple Silicon Mac:** Se requiere un Mac o PC con arquitectura Intel x64 o chip Apple M1 (o modelos posteriores). +``` + +## Requisitos de software + +```` +- macOS, Windows o Linux:** Para macOS, necesitarás una versión reciente compatible con Apple Silicon (arquitectura ARM) y la traducción Rosetta 2 para ejecutar aplicaciones x86_64. +Del mismo modo, para Windows o Linux, funcionará cualquier distribución reciente que se adapte a tus preferencias o requisitos. +- **Rosetta 2:** Esta capa de traducción permite ejecutar aplicaciones x86_64 en Apple Silicon. Es crucial para ejecutar software que aún no está optimizado para la arquitectura ARM. +- **Homebrew:** Se trata de un gestor de paquetes para macOS que se utiliza para instalar diversos programas, incluida la versión x86_64 de Java. Dependiendo de los requisitos del software, es posible que necesites las versiones ARM y x86_64 de Homebrew. +- **Chocolatey:** Se trata de un equivalente de Homebrew para Windows que permite instalar diversos programas, incluido Java JDK. +- **Java Development Kit (JDK):** Una versión de Java JDK compatible con ARM (como OpenJDK para ARM). +- **x86_64 JDK:** Para la compatibilidad con bibliotecas o aplicaciones específicas aún no disponibles para ARM, también se necesita una versión x86_64 de Java. Esto se puede instalar usando Homebrew bajo Rosetta 2. +- Docker:** Necesitas tener `docker` y `docker-compose` instalados localmente. Si no los tienes instalados, te recomendamos que sigas las directrices de la [documentación oficial de Docker](https://docs.docker.com/get-docker/) para su instalación y actualización. +- Node & NPM:** Utilizamos la versión `v18` de Node. Se recomienda gestionar las versiones de Node con [`nvm`](https://github.com/nvm-sh/nvm). Después de instalar nvm, ejecute estos comandos para instalar y cambiar a la versión 18 de Node: + ```bash + nvm install 18 + nvm use 18 + ``` + Para usar Node sin `nvm`, siga las instrucciones de instalación en la [web oficial] de Node(https://nodejs.org/en/). Tras la instalación, verifíquela ejecutando `node -v` en su línea de comandos, que mostrará la versión de Node instalada. Este paso asegura que Node está correctamente instalado en tu sistema. +- **Ethers:** La interacción con la blockchain se realiza utilizando [Ethers v5](https://docs.ethers.org/v5/). +```` + +## Primeros pasos con el relé RIF + +Para obtener una guía detallada paso a paso sobre cómo empezar a utilizar RIF Relay, consulte [Sample dApp](/developers/integrate/rif-relay/sample-dapp/). + +## Requisitos para el despliegue del contrato de relevo RIF + +### Casco + +- Utilizamos la versión `Hardhat` `v2.10.2` para las interacciones de blockchain. Para más detalles sobre cómo instalar Hardhat, siga las instrucciones del [sitio web de Hardhat](https://hardhat.org/hardhat-runner/docs/getting-started#installation). Utilice el prefijo `npx` para los comandos de Hardhat para garantizar el uso de la versión específica del proyecto. Verifique la instalación con `npx hardhat version`. Para la configuración, consulte `hardhat.config.ts`. Instrucciones detalladas de uso y configuración están disponibles en [Documentación de Hardhat](https://hardhat.org/docs). + +### Uso de Docker + +- Los componentes de RIF Relay pueden desplegarse usando Docker o localmente usando [Hardhat](#hardhat). En el repositorio se puede encontrar una guía para [RIF Relay Server](https://github.com/rsksmart/rif-relay-server#execute-as-a-docker-container). diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/integrate.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/integrate.md new file mode 100644 index 00000000..5678c5f4 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/integrate.md @@ -0,0 +1,306 @@ +--- +sidebar_label: Integraciones +sidebar_position: 200 +title: Integración de relés RIF +tags: + - rif + - sobre + - relé + - guía de integración +description: Integración de RIF Relay en una dApp +--- + +Esta guía repasa los métodos expuestos de RIF Relay que las dApps y wallets pueden consumir para proporcionar relaying como servicio, con el propósito de permitir a los usuarios pagar tarifas de transacción con tokens en un sistema particular. + +## Introducción + +Existen múltiples formas de integrar RIF Relay en un sistema. Se detallan a continuación. + +Además, es importante tener en cuenta que no _todos_ los componentes del relé RIF son necesarios para una integración satisfactoria, como se explica en la siguiente sección. + +## Requisitos + +### Contratos inteligentes de relevo RIF + +Es necesario desplegarlos y conocer sus direcciones. Para saber cómo hacerlo, consulte la página [Despliegue de contratos](/developers/integrate/rif-relay/deployment/) de esta guía. + +### Servidor de retransmisión RIF + +El Servidor de Retransmisión RIF es el componente fuera de la cadena encargado de recibir transacciones y enviarlas a los componentes dentro de la cadena, principalmente el Centro de Retransmisión RIF. El RIF Relay Hub gestiona la información sobre los RIF Relay Workers y los RIF Relay Managers, pero también se comunica con el resto de componentes de la cadena: los contratos Smart Wallets, Factory y Verifier. + +El RIF Relay Manager posee cuentas de RIF Relay Worker con fondos en moneda nativa. Para retransmitir una transacción, un Worker la firma y la envía al RIF Relay Hub pagando el gas consumido. En el caso de un flujo feliz, las transacciones se retransmitirán en última instancia a través del RIF Relay Hub, utilizando la biblioteca EIP-712. + +Para obtener más información al respecto, consulte la [Página de arquitectura](/developers/integrate/rif-relay/). + +Los usuarios pueden interactuar con el servidor de retransmisión RIF directa o indirectamente. En este último caso, un usuario puede comunicarse con un servidor de retransmisión RIF a través de un cliente de retransmisión RIF. Un cliente de retransmisión RIF conoce las direcciones de diferentes servidores de retransmisión RIF y puede enviar solicitudes en cadena a cualquiera de ellos. A continuación, el cliente de retransmisión RIF envía la transacción que desea patrocinar al servidor de retransmisión RIF mediante una solicitud HTTP. + +En cualquier caso, necesitarás tener el servidor instalado y funcionando. Para ello, consulta las siguientes guías: + +1. [Requisitos de instalación del relé RIF](/developers/integrate/rif-relay/installation-requirements/) +2. [RIF Relay Deployment](/developers/integrate/rif-relay/deployment/) + +### Cliente de retransmisión RIF + +La clase `RelayClient`, de la biblioteca RIF Relay Client, ayuda a crear una solicitud de retransmisión, buscar un servidor disponible y enviar la solicitud a través del protocolo http. + +Para crear un `RelayClient` debemos seguir los siguientes pasos: + +1. Establece la configuración. +2. Proveedor de set (éteres). +3. Crear instancia. + +```typescript +import { + RelayClient, + setEnvelopingConfig, + setProvider, +} from '@rsksmart/rif-relay-client'; + + setEnvelopingConfig({ + chainId: , + preferredRelays: , + relayHubAddress: , + deployVerifierAddress: , + relayVerifierAddress: , + smartWalletFactoryAddress: + }); + + setProvider(ethersProvider); + + const relayClient = new RelayClient(); +``` + +Dónde están las variables: + +- **ID_RED**: Identifica una red con la que interactuar. +- **MATRIZ_URL_DEL_SERVIDOR**: Una matriz de cadenas de URL de servidor de retransmisión con las que el RelayClient puede interactuar. +- \*\*DIRECCIÓN DEL CONCENTRADOR DE RETRANSMISIÓN: La dirección del contrato del concentrador de retransmisión. +- \*\*DIRECCIÓN DEL VERIFICADOR DE DESPLIEGUE: La dirección del contrato del verificador de despliegue. +- **DIRECCIÓN_DEL_VERIFICADOR_DE_RELÉ**: La dirección del contrato del verificador de retransmisión. +- **DIRECCIÓN_FÁBRICA_CARTERA_INTELIGENTE**: La dirección del contrato de fábrica del monedero inteligente. + +Después de establecer la configuración y el proveedor de éteres, podemos empezar a crear instancias desde el `Relay Client`. + +#### Gestor de cuentas + +El gestor `Account Manager` es un componente singleton de la biblioteca RIF Relay Client que ayuda a firmar transacciones de retransmisión. Este componente puede firmar las transacciones con una cuenta interna previamente añadida o utilizando un proveedor de monederos como [metamask](https://metamask.io/). El `Administrador de cuentas` buscará primero las cuentas añadidas manualmente y, si no encuentra ninguna, intentará utilizar el proveedor que se [configuró previamente](#rif-relay-client). + +El `Administrador de cuentas` acepta [Carteras Ethers V5](https://docs.ethers.org/v5/api/signer/#Wallet) como cuentas internas. + +Para interactuar con el `Administrador de Cuentas` debemos seguir los siguientes pasos: + +1. Obtener una instancia. +2. Añade una nueva cuenta. + +```typescript + import { + AccountManager, + } from '@rsksmart/rif-relay-client'; + + const accountManager = AccountManager.getInstance(); + + accountManager.addAccount(); +``` + +Dónde están las variables: + +- **OBJETO_CUENTA_INTERNA**: [Cartera Ethers V5](https://docs.ethers.org/v5/api/signer/#Wallet) objeto. + +### Transacción de retransmisión + +Para retransmitir transacciones necesitamos un monedero inteligente ya desplegado, el proceso de despliegue y definición de un monedero inteligente se puede encontrar [Monedero Inteligente](/developers/integrate/rif-relay/smart-wallets). + +Los pasos que debemos seguir son: + +1. Despliega el monedero inteligente. +2. Cree la transacción que queremos retransmitir. +3. Retransmita la transacción. + +```typescript + const relayTransactionOpts: UserDefinedEnvelopingRequest = { + request: { + from: , + data: , + to: , + tokenContract: , + tokenAmount: , + }, + relayData: { + callForwarder: , + }, + }; + + const transaction: Transacción = await relayClient.relayTransaction( + relayTransactionOpts +); +``` + +Dónde están las variables: + +- **EOA**: Cuenta de propiedad externa, el propietario del monedero inteligente. +- **DATOS_A_EJECUTAR**: La función codificada que queremos retransmitir. +- **DIRECCIÓN_DESTINO**: La dirección del contrato destino que queremos ejecutar. +- **DIRECCIÓN_TOKEN**: La dirección del contrato token que queremos utilizar para pagar la tasa. +- **CANTIDAD_DE_TOKENS_EN_WEI**: La cantidad que queremos pagar por la tasa en wei. +- **DIRECCIÓN_CARTERA_INTELIGENTE**: La dirección del monedero inteligente que va a ejecutar la transacción retransmitida. + +### Verificadores de relés + +Para obtener las direcciones de los verificadores necesitamos ejecutar el comando: + +``` +curl http:///verifiers +``` + +> El comando debe ejecutarse en un terminal diferente, ya que necesita que el servidor esté en ejecución para realizar la solicitud. + +```json + { + "trustedVerifiers": [ + "0x03f23ae1917722d5a27a2ea0bcc98725a2a2a49a", + "0x73ec81da0c72dd112e06c09a6ec03b5544d26f05" + ] + } +``` + +### Solicitud de construcción + +Para retransmitir transacciones, el Servidor de Retransmisión expone un gestor de envíos HTTP a la siguiente ruta `http:///relay`. El Cliente de Retransmisión proporciona una abstracción para construir y enviar cada transacción a los servidores disponibles; aunque el cliente puede simplificar la interacción con el servidor, siempre es posible enviar peticiones HTTP al servidor sin utilizar el Cliente de Retransmisión. + +Cada transacción que se envíe debe tener la siguiente estructura: + +```json + { + "relayRequest": "", + "metadata": "" + } +``` + +A continuación describiremos cada campo que se requiere en la solicitud. + +#### Solicitud de relé + +```json + { + "request": { + "relayHub": "0xDA7Ce79725418F4F6E13Bf5F520C89Cec5f6A974", + "to": "0x1Af2844A588759D0DE58abD568ADD96BB8B3B6D8", + "data": "0xa9059cbb00000000000000000000000000000000c60b724c0865e294d64c94fed89c1e90bce0a7fe0000000000000000000000000000000000000000000000000000000000008ac7230489e80000", + "from": "0x553f430066ea56bd4fa9190218af17bad23dcdb1", + "value": "0", + "nonce": "1", + "tokenAmount": "2803630780191436371", + "tokenGas": "31643", + "tokenContract": "0x726ECC75d5D51356AA4d0a5B648790cC345985ED", + "gas": "31515", + "validUntilTime": 1676747217, + }, + "relayData": { + "gasPrice": "60000000", + "callVerifier": "0x03F23ae1917722d5A27a2Ea0Bcc98725a2a2a49a", + "callForwarder": "0x1C8bb3b6809b92F2e38e305FD6bDE9687Bb4ba54", + "feesReceiver": "0x9C34f2225987b0725A4201F1C6EC1adB35562126" + } + } +``` + +Donde está cada clave de `request`: + +- **RelayHub**: La dirección del hub de retransmisión que se utilizará para validar la persona que llama desde la transacción. +- **a**: La dirección del contrato destino que queremos ejecutar. +- **datos**: La función codificada que queremos retransmitir. +- **de**: Cuenta de titularidad externa, el propietario del monedero inteligente. +- **Valor**: El valor de la moneda nativa que se quiere transferir desde smart wallet durante la ejecución. +- **nonce**: Smart Wallet [nonce](https://github.com/rsksmart/rif-relay-contracts/blob/d1b1ee1c429786f967205f32ed015b3f9a1edaaf/contracts/smartwallet/SmartWallet.sol#L18) para evitar ataques de repetición. +- **importe del token**: La cantidad de token que queremos pagar por la cuota en wei. +- **tokenGas**: El límite de gas para la transacción de pago de tokens. +- **ContratoToken**: La dirección del contrato token que queremos utilizar para pagar la tasa. +- **gas**: El límite de gas para la ejecución de la operación de retransmisión. +- **validUntilTime**: Tiempo de expiración de la transacción en segundos. + +Donde está cada clave de `relayData`: + +- **PrecioGas**: El precio del gas que se utilizará para retransmitir la transacción. +- **Llamada al verificador**: La dirección del verificador del relé para validar la corrección de la transacción. +- **callForwarder**: La dirección del monedero inteligente que va a ejecutar la transacción. +- **Recibidor**: La dirección del trabajador o contrato cobrador que va a recibir las comisiones. + +#### Solicitud de despliegue + +```json + { + "request": { + "relayHub": "0xDA7Ce79725418F4F6E13Bf5F520C89Cec5f6A974", + "to": "0x000000000000000000000000000000000000000000000000", + "data": "0x", + "from": "0x553f430066EA56BD4fa9190218AF17bAD23dCdb1", + "value": "0", + "nonce": "0", + "tokenAmount": "0", + "tokenGas": "0", + "tokenContract": "0x1Af2844A588759D0DE58abD568ADD96BB8B3B6D8", + "recoverer": "0x0000000000000000000000000000000000000000000000000000", + "index": "1", + "validUntilTime": 1676747036, + }, + "relayData": { + "gasPrice": "60000000", + "callVerifier": "0x73ec81da0C72DD112e06c09A6ec03B5544d26F05", + "callForwarder": "0xE0825f57Dd05Ef62FF731c27222A86E104CC4Cad", + "feesReceiver": "0x9C34f2225987b0725A4201F1C6EC1adB35562126" + } + } +``` + +Donde está cada clave de `request`: + +- **RelayHub**: La dirección del hub de retransmisión que se utilizará para validar la persona que llama desde la transacción. +- **a**: La dirección del contrato destino que queremos ejecutar (`0x000000000000000000000000000000000000000000000000` para el despliegue de Cartera Inteligente). +- **Datos**: La función codificada que queremos retransmitir (`0x` para el despliegue de Smart Wallet). +- **de**: Cuenta de titularidad externa, el propietario del monedero inteligente. +- **Valor**: El valor de la moneda nativa que se quiere transferir desde smart wallet durante la ejecución. +- **nonces**: SmartWalletFactory mantiene un registro de los [nonces](https://github.com/rsksmart/rif-relay-contracts/blob/d1b1ee1c429786f967205f32ed015b3f9a1edaaf/contracts/factory/SmartWalletFactory.sol#L95) utilizados por cada propietario de cartera inteligente, para evitar ataques de repetición. Se puede recuperar con [`IWalletFactory.nonce(from)`](https://github.com/rsksmart/rif-relay-contracts/blob/d1b1ee1c429786f967205f32ed015b3f9a1edaaf/contracts/interfaces/IWalletFactory.sol#L8) +- **importe de la ficha**: El importe que queremos pagar por la cuota en wei. +- **tokenGas**: El límite de gas para la transacción de pago de tokens. +- **ContratoToken**: La dirección del contrato token que queremos utilizar para pagar la tasa. +- **Recuperador**: La dirección del recuperador, para recuperar fondos del monedero inteligente. Esta funcionalidad está pendiente de implementar. +- **Índice**: El índice del monedero inteligente que queremos desplegar. +- **validUntilTime**: Tiempo de expiración de la transacción en segundos. + +Donde está cada clave de `relayData`: + +- **PrecioGas**: El precio del gas que se utilizará para retransmitir la transacción. +- **Llamada al verificador**: La dirección del verificador de despliegue para validar la corrección de la transacción. +- **callForwarder**: La dirección de fábrica del monedero inteligente que va a realizar el despliegue. +- **receptorDeCuotas**: La dirección del contrato de trabajador o cobrador que va a recibir las comisiones. + +#### Metadatos + +```json + { + "relayHubAddress": "0xDA7Ce79725418F4F6E13Bf5F520C89Cec5f6A974", + "signature": "0xa9f579cf964c03ac194f577b5fca5271ba13e2965c...", + "relayMaxNonce": 4 +} +``` + +Dónde está cada llave: + +- **Dirección del centro de retransmisión**: El hub de retransmisión que utilizará el servidor para retransmitir la transacción. +- **Firma**: La transacción de retransmisión firmada por el propietario. Después de firmar la transacción, no se puede cambiar, ya que hay una validación en la cadena que forma parte de la EIP712. +- **RelayMaxNonce**: Relay worker nonce más un gap extra. + +### Función personalizada de reposición de trabajadores + +Cada transacción retransmitida es firmada por una cuenta de trabajador de retransmisión. Las cuentas de los trabajadores están controladas por el Gestor de Retransmisiones. Cuando un trabajador de retransmisión firma y retransmite una transacción, el coste de esa transacción se paga utilizando los fondos de la cuenta de ese trabajador. Si la transacción no está subvencionada, el trabajador es compensado con fichas. + +Las cuentas de los trabajadores deben tener siempre un saldo mínimo para pagar la gasolina de la transacción. Estos saldos pueden gestionarse implementando una estrategia de reposición. El Gestor de Retransmisiones puede utilizar la estrategia para recargar la cuenta de un trabajador de retransmisión cuando el saldo sea demasiado bajo. + +Proporcionamos una implementación por defecto para una estrategia de reabastecimiento. Los integradores de soluciones de RIF Relay pueden implementar su propia estrategia de reposición. + +Para aplicar y utilizar su propia estrategia de reposición: + +1. En la carpeta `src` del proyecto RIF Relay Server, abre `ReplenishFunction.ts` con un editor de texto. +2. En la función `replenishStrategy` escribe tu nueva estrategia de reposición. +3. Reconstruir el proyecto `npm run build` +4. Cambie el archivo JSON de configuración para establecer `customReplenish` en true. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/overview.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/overview.md new file mode 100644 index 00000000..f68ae3f9 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/overview.md @@ -0,0 +1,22 @@ +--- +sidebar_label: Visión general +sidebar_position: 100 +title: RIF Relay - Visión general +tags: + - rif + - sobre + - relé + - integrar + - guía de integración +description: Visión general del relé RIF +--- + +La mayoría de las cadenas de bloques tienen criptomoneda nativa para pagar las tasas de transacción y el consumo de gas; este sencillo diseño tiene muchas ventajas. En primer lugar, para poner en marcha una economía, el modelo de criptomoneda nativa crea una demanda inicial. En segundo lugar, simplifica la interacción entre usuarios y mineros porque les obliga a utilizar el mismo medio de pago. En tercer lugar, reduce la complejidad de las reglas de consenso. Por último, proporciona protección contra la denegación de servicio (DoS) a la red, ya que los nodos llenos pueden pagar lo que los mineros esperan incluir en una transacción recibida. De este modo, los nodos pueden decidir propagar o no una transacción, evitando el consumo gratuito del ancho de banda de la red, y detener las transacciones spam. + +Las criptomonedas tienden a asociarse con la volatilidad y, para contrarrestar este hecho, se introdujeron las Stablecoins. Las stablecoins tienden un puente entre el mundo de las criptomonedas y el de la moneda fiduciaria, ya que sus precios están vinculados a un activo de reserva como el dólar estadounidense o el oro. + +Pero con la llegada de las Finanzas Descentralizadas (DeFi), varias monedas estables se han convertido en el medio preferido de pago y ahorro tanto para usuarios como para mineros, por lo que se han creado sistemas independientes para facilitar mecanismos de pago alternativos. Las transacciones que permiten pagar operaciones con cualquier moneda que no sea la nativa se denominan meta-transacciones porque en algunos sistemas la transacción del usuario está incrustada en una transacción de nivel superior (o meta) creada por un tercero. Un término más accesible para estas transacciones es "sobres" o, para el conjunto del sistema, un sistema de relés. Una metatransacción/sistema de retransmisión puede servir al menos para dos casos de uso diferentes: 1) pagar las tasas de transacción con tokens, donde una nueva parte recibe los tokens (del usuario) y paga las tasas en nombre del usuario, y 2) permitir a los desarrolladores de contratos inteligentes subvencionar el gas utilizado para interactuar con sus contratos. + +Teniendo esto en cuenta, el objetivo principal del proyecto RIF Relay es **proporcionar al ecosistema Rootstock (RSK) los medios para permitir que las aplicaciones de blockchain y los usuarios finales (wallet-apps) realicen transacciones sin necesidad de RBTC**. El sistema debe permitir a los usuarios de Rootstock (RSK) pagar las tasas de transacción con métodos de pago (es decir, tokens) distintos de RBTC, manteniendo al mismo tiempo sus cuentas como remitentes de transacciones. + +RIF Relay se inspira en el proyecto [Gas Station Network (GSN)](https://github.com/opengsn/gsn). GSN es un sistema descentralizado que mejora la usabilidad de la dApp sin sacrificar la seguridad. En pocas palabras, GSN se abstrae del gas (utilizado para pagar las tasas de transacción) para minimizar las fricciones en la integración y la experiencia de usuario de las aplicaciones digitales. Con GSN, los "clientes sin gas" pueden interactuar con contratos inteligentes pagando por el gas con tokens en lugar de moneda nativa. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/sample-dapp.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/sample-dapp.md new file mode 100644 index 00000000..0e57c588 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/sample-dapp.md @@ -0,0 +1,144 @@ +--- +sidebar_label: RIF Relay Ejemplo de dApp +sidebar_position: 400 +title: Cómo utilizar RIF Relay Sample dApp SDK +tags: + - rif + - sobre + - relé + - guía de integración +description: RIF Relay Sample dApp SDK Kit de inicio +--- + +## Primeros pasos + +Esta guía ayuda a comenzar rápidamente con la configuración de su entorno para utilizar RIF Relay y también a utilizar la dApp de ejemplo para probar los servicios de relé. + +### Paso 1: Ejecutar el nodo Portainjerto + +Necesita configurar y ejecutar un nodo Rootstock, preferiblemente la última versión de RSKj releases. El nodo puede funcionar localmente o a través de Docker. En ambos casos, se utiliza un archivo [`node.conf`](https://github.com/rsksmart/rif-relay/blob/main/docker/node.conf). + +Consulte la [Guía de instalación del nodo Rootstock](/node-operators/setup/installation/) para obtener una guía detallada sobre este paso. + +### Paso 2: Añadir red a Metamask + +Para interactuar con la red Rootstock, es necesario añadirla a Metamask. Dado que estamos utilizando el nodo en `--regtest mode`, siga la guía de Metatmask en [Cómo añadir una red personalizada RPC](https://support.metamask.io/hc/en-us/articles/360043227612-How-to-add-a-custom-network-RPC) y añada la red Rootstock RegTest a Metamask con los siguientes datos: + +```text +- Nombre de la red: RSK regtest +- Nueva URL RPC: http://127.0.0.1:4444 +- ID de cadena: 33 +- Símbolo de moneda: tRBTC +``` + +Para obtener más información sobre Metatmask y cómo añadirlo a Rootstock mediante programación, consulte [Metamask](/dev-tools/wallets/metamask/) y [Cómo añadir Metamask a Rootstock mediante programación](/resources/tutorials/rootstock-metamask/). + +### Paso 3: Establecer contratos de relevo RIF + +Para configurar el contrato de retransmisión RIF, clone el repositorio de contratos de retransmisión RIF: https://github.com/rsksmart/rif-relay-contracts, a continuación, siga la guía [Despliegue de retransmisión RIF](/developers/integrate/rif-relay/deployment/) para desplegar un contrato de retransmisión RIF, habilitar el reparto de ingresos y poner el token en la lista blanca permitiéndolo. + +````mdx-code-block + + + Comprobar tokens permitidos + + ```bash + npx hardhat allowed-tokens --network regtest + ``` + Respuesta: + ```bash + rif-relay-contracts % npx hardhat allowed-tokens --network regtest + deployVerifier [ '0x6f217dEd6c86A57f1211F464302e6fA544045B4f' ] + relayVerifier [ '0x6f217dEd6c86A57f1211F464302e6fA544045B4f' ] + customDeployVerifier [ '0x6f217dEd6c86A57f1211F464302e6fA544045B4f' ] + customRelayVerifier [ '0x6f217dEd6c86A57f1211F464302e6fA544045B4f' ] + nativeHolderDeployVerifier [ '0x6f217dEd6c86A57f1211F464302e6fA544045B4f' ] + nativeHolderRelayVerifier [ '0x6f217dEd6c86A57f1211F464302e6fA544045B4f' ] + ``` + + + + Acuñar ficha + + - Para acuñar nuevas unidades del `UtilToken` en la dirección del monedero de Metamask: + - Vaya al monedero de Metamask y copie la dirección del monedero: + - Ejecute el comando para acuñar el token, donde: + + - `--token-address` → esta es la dirección del `UtilToken` + - `--amount` → cantidad a acuñar + - `--receiver` → dirección del monedero + ```bash + npx hardhat mint \4 --token-address 0x6f217dEd6c86A57f1211F464302e6fA544045B4f \ + --amount 10000000000000000000 \ + --receiver \ + --network regtest + `` + - Importa el token acuñado al monedero. + - Para ver el token en la cartera, haga clic en "importar tokens" y, a continuación, pegue la dirección del token. + + + +```` + +### Paso 4: Configurar el servidor de retransmisión RIF + +Clone el [Repositorio del servidor de retransmisión RIF](https://github.com/rsksmart/rif-relay-server) y, a continuación, consulte [Ejecutar el servidor de retransmisión RIF](/developers/integrate/rif-relay/deployment#run-the-rif-relay-server) para obtener una guía completa sobre la configuración del servidor de retransmisión RIF. + +## RIF Relay Ejemplo de dApp + +Esta dApp de ejemplo le muestra cómo enviar transacciones a la blockchain de Rootstock utilizando el [RIF Relay Sample dApp SDK](https://github.com/rsksmart/rif-relay-sample-dapp). Necesitarás conectar la dApp con MetaMask para firmar transacciones con la cuenta que gestiona tus Smart Wallets. + +### Clonar repositorio SDK e instalar dependencias + +```bash + # clone repository + git clone https://github.com/rsksmart/relaying-services-sdk-dapp + cd relaying-services-sdk-dapp + # install dependencies + npm install --force +``` + +- Configurar variables de entorno + +Crea un nuevo fichero llamado `.env` en el directorio superior, y añade las siguientes líneas en él (con las direcciones de los contratos generadas cuando desplegamos los contratos) en la sección **Set up RIF Relay Contracts** anterior: + +```bash + REACT_APP_CONTRACTS_RELAY_HUB=0x463F29B11503e198f6EbeC9903b4e5AaEddf6D29 + REACT_APP_CONTRACTS_DEPLOY_VERIFIER=0x14f6504A7ca4e574868cf8b49e85187d3Da9FA70 + REACT_APP_CONTRACTS_RELAY_VERIFIER=0xA66939ac57893C2E65425a5D66099Bc20C76D4CD + REACT_APP_CONTRACTS_SMART_WALLET_FACTORY=0x79bbC6403708C6578B0896bF1d1a91D2BB2AAa1c + REACT_APP_CONTRACTS_SMART_WALLET=0x987c1f13d417F7E04d852B44badc883E4E9782e1 + + REACT_APP_RIF_RELAY_CHAIN_ID=33 + REACT_APP_RIF_RELAY_GAS_PRICE_FACTOR_PERCENT=0 + REACT_APP_RIF_RELAY_LOOKUP_WINDOW_BLOCKS=1e5 + REACT_APP_RIF_RELAY_PREFERRED_RELAYS=http://localhost:8090 +<<<<<<< HEAD + REACT_APP_BLOCK_EXPLORER=https://explorer.testnet.rootstock.io +======= + REACT_APP_BLOCK_EXPLORER=https://explorer.testnet.rootstock.io/ +>>>>>>> main +``` + +### Ejecutar la dApp + +```bash + # ejecuta la aplicación en el entorno regtest + ENV_VALUE="regtest" npm run start +``` + +![Ejecutar la dApp](/img/rif-relay/starter-kit/run-the-dapp.png) + +- Conectar el monedero metamask para firmar + +Conectar monedero Metamask](/img/rif-relay/starter-kit/connect-metamask-wallet.png) + +- Crear un nuevo monedero inteligente + +Crear un nuevo monedero inteligente](/img/rif-relay/starter-kit/create-smart-wallet.png) + +- Acuñar fichas en el monedero + - Para comandos a token de menta, Ver paso 6 en la sección Configurar contratos de retransmisión RIF más arriba. + Mint Tokens](/img/rif-relay/starter-kit/mint-tokens.png) +- Transferencia a diferentes direcciones, utilizando TKN para el pago de las tasas de transferencia, en lugar de RBTC + ![Transferencia utilizando TKN](/img/rif-relay/starter-kit/transfer-using-tkn.png) diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/smart-wallets.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/smart-wallets.md new file mode 100644 index 00000000..69332dd3 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/smart-wallets.md @@ -0,0 +1,80 @@ +--- +sidebar_label: Billeteras inteligentes +sidebar_position: 700 +title: Billeteros inteligentes RIF Relé +tags: + - rif + - sobre + - relé + - usuario + - guía +description: Billetera inteligente RIF Relay +--- + +Esta guía pretende explicar más sobre la interacción y despliegue de las Carteras Inteligentes. Utilizaremos contratos de prueba adicionales que se incluyeron en el proyecto, como el `UtilToken(ERC20)`. Todos los scripts utils se ejecutan desde la cuenta[0] de la red regtest. + +## Requisitos previos + +- Siga el proceso de despliegue de la [Guía de despliegue](/developers/integrate/rif-relay/deployment). +- La definición del monedero inteligente puede encontrarse en [Arquitectura](/developers/integrate/rif-relay/architecture/) + +## Formas de crear carteras inteligentes + +Hay **dos maneras** de crear una Cartera Inteligente: + +1. **Transacción regular:** El Solicitante (u otra cuenta en nombre del Solicitante) llama a la Fábrica de Proxy pidiendo obtener una nueva Cartera Inteligente. Por lo tanto, la Fábrica de Proxy crea un proxy para el código SmartWallet, delegando la propiedad al Solicitante. +2. **Patrocinado:** Necesita pasar por el proceso de Relevo RIF, que se describe en detalle más adelante. El solicitante pide a un tercero que pague por el despliegue de la Cartera Inteligente, y el solicitante paga en tokens por ello (o gratis si está subvencionado por el tercero, también conocido como Patrocinador). + +## Enviar fondos + +En el [RIF Relay Contracts](https://github.com/rsksmart/rif-relay-contracts) hay un script que nos ayudaría a acuñar tokens ERC20. + +Necesitamos ejecutar el siguiente script: + +```shell +npx hardhat mint --token-dirección <0xabc123> --importe --receptor <0xabc123> --red regtest +``` + +> El contrato de tokens debe tener una función de acuñación. + +## Implantar un monedero inteligente + +Para desplegar un monedero inteligente necesitamos seguir algunos pasos que se describirán a continuación: + +1. Necesitamos generar la dirección del monedero inteligente. Como hemos mencionado antes, el monedero inteligente es una cuenta basada en contratos, por lo tanto, podemos generar tantas direcciones de monedero inteligente como queramos sin gastar gasolina llamando a `getSmartWalletAddress` desde la librería del cliente relé. + +> Un monedero inteligente sólo necesita desplegarse cuando necesitamos ejecutar una transacción. El proceso de despliegue utiliza gas, así que, a menos que esté subvencionado, tenemos que pagarlo. + +En este punto deberíamos tener el objeto Relay Client creado. + +```typescript + import type { + getSmartWalletAddress, + UserDefinedDeployRequest, + } from '@rsksmart/rif-relay-client'; + + const smartWalletAddress = await getSmartWalletAddress(, ); + + const relayTransactionOpts: UserDefinedDeployRequest = { + request: { + from: , + tokenContract: , + tokenAmount: , + index: , + }, + }; + + const transaction = await relayClient.relayTransaction( + relayTransactionOpts + ); + +``` + +> Ten en cuenta que para pagar cualquier cantidad de tokens durante el despliegue, el monedero inteligente debe recibir fondos primero. + +Dónde están las variables: + +- **EOA**: Cuenta de propiedad externa, el propietario del monedero inteligente. +- **INDEX**: El índice que queremos utilizar para generar el monedero inteligente. +- **DIRECCIÓN_TOKEN**: La dirección del contrato token que queremos utilizar para pagar la tasa. +- **CANTIDAD_DE_TOKENS_EN_WEI**: La cantidad que queremos pagar por la tasa en wei. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/versions.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/versions.md new file mode 100644 index 00000000..487ee6f1 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/01-rif-relay/versions.md @@ -0,0 +1,67 @@ +--- +sidebar_label: Versiones +sidebar_position: 900 +title: Versiones del relé RIF +tags: + - rif + - sobre + - relé rif + - guía de integración +description: Versiones del relé RIF +--- + +La primera iteración de RIF Relay se basó en el gran trabajo realizado por el [equipo de la Red de Gasolineras](https://www.opengsn.org/). + +## Versión 0.1 + +RIF Relay V0.1 comenzó como una bifurcación de GSN con dos objetivos en mente: + +- Ser compatible con los contratos inteligentes existentes y futuros sin necesidad de adaptar dichos contratos para que funcionen con RIF Relay. +- Sea lo más rentable posible. + +## Versión 0.2 + +### Visión general + +RIF Relay V0.2 es un rediseño de GSN. Reduce los costes de gas y simplifica la interacción entre los distintos contratos que forman parte del sistema. Esto se consigue mediante: + +- Despliegue seguro de proxies Smart Wallet contrafactuales para cada cuenta de usuario: esto elimina la necesidad de depender de las funciones `_msgSender()` y `_msgData()`, haciendo que los contratos existentes y futuros sean compatibles con RIF Relay sin ninguna modificación. +- Permitir a los repetidores recibir fichas en una dirección de trabajador bajo su control y decidir qué hacer con los fondos posteriormente. +- Reducción de los costes de gas mediante la optimización de la arquitectura GSN. + +Nuestro principal objetivo es proporcionar al ecosistema de Rootstock (RSK) los medios para permitir que las aplicaciones de blockchain y los usuarios finales (wallet-apps) paguen las tasas de transacción utilizando tokens (por ejemplo, tokens RIF), y así eliminar la necesidad de adquirir RBTC por adelantado. + +Es importante recordar que, como medida de seguridad, los contratos de la V0.1 desplegados en Mainnet tienen límites en las cantidades apostadas para operar; estos límites se eliminaron en la V0.2. + +### Detalles + +- El contrato RelayHub ya no recibe pagos, el pago por el servicio (en tokens) se envía ahora directamente al trabajador que retransmite la transacción en nombre del usuario. +- El contrato RelayHub gestiona ahora el replanteo del gestor de relés. +- Mejoras en la estimación del gas: + - Se ha eliminado la sobrecarga de gas de RelayHub; ya no hay validaciones contra valores codificados. + - Los campos de gas y gas simbólico de la solicitud pueden dejarse ahora sin definir y, en ese caso, serán estimados automáticamente por el cliente de retransmisión RIF. + - La estimación del gas máximo en el servidor de retransmisión RIF es ahora más precisa. + - Se dispone de una nueva función de utilidad para estimar el gas máximo que consumiría una transacción de retransmisión, basada en una estimación de ajuste lineal. Esto puede utilizarse en aplicaciones que no quieren firmar una carga útil cada vez que necesitan una aproximación del coste de retransmitir la transacción. +- Las verificaciones de los pagadores se realizan fuera de la cadena para optimizar los costes de gas, por lo que los pagadores se llaman ahora Verificadores y no forman parte del flujo de retransmisión en la cadena ni gestionan pagos en absoluto. +- Optimización del coste del gas. +- Problemas de seguridad. + +## Versión 1 + +### Visión general + +La inclusión de un mecanismo de reparto de ingresos en el servicio RIF Relay no supone una penalización en el precio para los usuarios de RIF Relay. Modificamos la dirección utilizada para recibir el pago (en tokens) por una retransmisión (o despliegue) de transacción satisfactoria. + +En la implementación V0.2, el RelayRequest y el DeployRequest incluyen un atributo relayWorker para identificar qué cuenta pagó el gas. El RIF Relay SmartWallet paga directamente a esta cuenta el número de tokens negociados para el servicio Relay (o Deploy). En la V1 se eliminó el atributo relayWorker de las peticiones RelayRequest y DeployRequest. Se implementó y configuró un nuevo atributo llamado feesReceiver en el RelayServer + +Este cambio no alteró el actual flujo de relés, manteniendo su coste como hasta ahora, y también introdujo la flexibilidad necesaria para aplicar cualquier estrategia de reparto de ingresos. + +- El feesReceiver puede ser el trabajador o el contrato MultSig. +- La SmartWallet pagará al feesReceiver. El feesReceiver guardará los fondos de cada pago del usuario. +- Tras el pago desde la SmartWallet, el feesReceiver no realizará ninguna lógica de distribución para evitar aumentar el coste del servicio de retransmisión para el usuario. +- Con este planteamiento, no es necesario modificar el flujo de retransmisión, por lo que la introducción de un mecanismo de reparto de ingresos no repercutirá en el precio del servicio de retransmisión. +- Los participantes pertinentes formarán parte del contrato MultiSig. + - El contrato MultiSig especifica qué parte de los fondos recaudados va a cada participante (por ejemplo, el operador del servidor de retransmisión, el proveedor del monedero y el proveedor de liquidez podrían ser los participantes). + - Posteriormente, un proceso fuera de la cadena activará el proceso de distribución desde el contrato. Este proceso puede invocar la función de distribución una vez a la semana, al mes o cuando los fondos del contrato superen un determinado umbral. + - Los participantes pueden modificar los parámetros de reparto (por ejemplo, los porcentajes utilizados para el reparto entre los participantes) si están de acuerdo en los cambios concretos. + - Pueden existir múltiples estrategias de reparto de ingresos, idealmente una por grupo de participantes. diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/_category_.yml b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/_category_.yml new file mode 100644 index 00000000..c5c7800d --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/06-integrate/_category_.yml @@ -0,0 +1,5 @@ +label: Guías de integración +position: 7 +link: + type: índice-generado + slug: /desarrolladores/integrar/ diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/07-rpc-api/01-setup.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/07-rpc-api/01-setup.md new file mode 100644 index 00000000..604a4943 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/07-rpc-api/01-setup.md @@ -0,0 +1,127 @@ +--- +sidebar_label: Primeros pasos +sidebar_position: 100 +title: Introducción a la API RPC +tags: + - grifo + - Portainjerto + - red de pruebas + - dirección + - cartera + - herramientas +description: Cree, interactúe y despliegue fácilmente contratos inteligentes compatibles con EVM utilizando un sólido conjunto de métodos JSON RPC disponibles a través de la API RPC. +--- + +La [RPC API](http://rpc.rootstock.io/) proporciona una interfaz web intuitiva y sin fisuras para que los desarrolladores interactúen con los [nodos Rootstock](/node-operators/setup/) a través de los métodos [JSON-RPC](/node-operators/json-rpc/methods/). Su objetivo es abordar los retos a los que se enfrentan los desarrolladores cuando intentan acceder a información crítica como registros, transacciones y balances a través de RPC, lo que puede afectar significativamente al desarrollo oportuno de dApps en la blockchain de Rootstock. + +En esta guía aprenderás: + +- Cómo crear una cuenta y [realizar su primera llamada a la API](#comienzo) +- Ver una lista de [métodos JSON-RPC](/node-operators/json-rpc/methods/) disponibles. + +[Utilizar la API RPC](http://rpc.rootstock.io/) + +## ¿A quién va dirigido? + +- Desarrolladores de dApp que deseen interactuar con los nodos Rootstock + +## Características + +\*\*Fácil instalación + +- Cree una clave API sin esfuerzo para iniciar el desarrollo. +- Realice la primera llamada a la API en cuestión de minutos. + +\*\*Autenticación de clave API + +- Proporciona autenticación segura para aplicaciones descentralizadas (dApps). +- Limita las solicitudes de API diaria o mensualmente. + +## Primeros pasos + +:::info[Note] +La [API RPC](https://rpc.rootstock.io/) está disponible en TESTNET y MAINNET. +::: + +Visite la [Rootstock RPC API](https://rpc.rootstock.io/) + +
+ RPC API Landing Page +
+ +### Obtener una cuenta GRATUITA + +Para crear una cuenta, pulse en _Inscribirse_. + +
+ RPC API Sign Up +
+ +### Obtener una clave API + +Para obtener una clave API: + +Acceda al panel de control y haga clic en _Nueva clave API_: + +```mdx-code-block +
+ Generate an API key +
+``` + +Elige un nombre para identificar tu `apikey`, y la Red (ya sea `Testnet` o `Mainnet`). También puedes añadir una descripción (opcional). Haz clic en **Crear**. + +```mdx-code-block +
+ Create API key +
+``` + +### Realizar la primera llamada a la API + +Haz clic en el `apikey` recién creado para obtener los detalles: + +```mdx-code-block +
+ Make First API Call +
+``` + +Puedes hacer tu primera llamada api usando uno de los ejemplos proporcionados, o simplemente añadiendo una url y `apikey` a tu aplicación. + +```mdx-code-block +
+ Connect API +
+``` + +#### Ejemplo de solicitud + +```shell +curl --location --request POST 'https://rpc.testnet.rootstock.io/' \ +--header 'Content-Type: application/json' \ +--data ' { +"jsonrpc": "2.0", +"method": "eth_blockNumber", +"params": [], +"id": 0 +}' +``` + +**Respuesta:** + +```text +{"jsonrpc":"2.0","id":0,"result":"0x4b7eca"} +``` + +> El límite diario es de 25.000 peticiones por usuario, y cada usuario puede tener hasta 4 claves API, lo que permite una fácil diferenciación para las distintas aplicaciones que el usuario quiera probar. + +## Obtener asistencia + +Únete al [Rootstock Discord](https://rootstock.io/discord) para obtener ayuda o dar tu opinión. + +## Enlaces útiles + +- Métodos [JSON RPC] admitidos (/node-operators/json-rpc/methods/) +- [Guía de inicio rápido con Hardhat](/developers/smart-contracts/hardhat/) +- [Grifo RBTC](https://faucet.rootstock.io/) diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/07-rpc-api/02-methods.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/07-rpc-api/02-methods.md new file mode 100644 index 00000000..8c72cd70 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/07-rpc-api/02-methods.md @@ -0,0 +1,1172 @@ +--- +sidebar_label: RPC API Methods +sidebar_position: 200 +title: RPC API Methods +tags: [faucet, Rootstock, rpc api, testnet, address, wallet, tools] +description: "Easily create, interact and deploy EVM compatible smart contracts using a robust set of JSON RPC methods available through the RPC API." +--- + +Find below a list of methods available on the RPC API. See [how to setup the RPC API](/developers/rpc-api/setup/). + +## eth_accounts +- _Method:_ `eth_accounts` + - Returns a list of addresses owned by the client. Since Rootstock RPC API does not store keys, this will always return empty. +- _Params:_ None + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_accounts", + "params":[], + "id":0 + }' + ``` + - **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": [] + } + ``` +## eth_blockNumber +- _Method:_ `eth_blockNumber` + - Returns the number of the most recent block. +- _Params:_ None + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_blockNumber", + "params":[], + "id":0 + }' + ``` +- Example Response: + ```text + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x4bdcfb" + } + ``` +## eth_call +- Executes a new message call immediately without creating a transaction on the blockchain. +- _Params:_ + - `transaction`: object, the transaction call object which contains the following fields: + - **from:** String, the address from which the transaction is sent + - **to:** String, required, the address to which the transaction is addressed + - **gas:** String, the integer of gas provided for the transaction execution + - **gasPrice:** String, the integer of the `gasPrice` used for each paid gas, encoded as a hexadecimal + - **value:** String, the integer of value sent with this transaction encoded as hexadecimal + - **data:** string, the hash of the method signature and encoded parameters. For more information, see the Contract ABI description in the [Solidity documentation](https://docs.soliditylang.org/en/latest/abi-spec.html) + - `blockNumber`: String, required. The number of the block (in hex) from which the number of transactions is required, OR one of the following block tags: + - **latest:** the most recent block the client has available. + - **earliest:** the lowest numbered block the client has available. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from a local mempool. Intuitively, you can think of these as blocks that have not been mined yet. +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_call", + "params":[{"from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155", + "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567", + "gas": "0x76c0", + "gasPrice": "0x9184e72a000", + "value": "0x9184e72a", + "data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"}, + "latest" + ], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x" + } + ``` +## eth_chainId + - _Method:_ `eth_chainId` + - Returns the number of the network, in hexadecimal value. + - _Params:_ None +- _Responses:_ + - `0x1f` -> Rootstock Testnet + - `0x1e` -> Rootstock Mainnet +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_chainId", + "params":[], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x1f" + } + ``` +## eth_estimateGas +- _Method:_ + - Generates and returns an estimate of how much gas is necessary to allow the transaction to complete. The transaction will not be added to the blockchain. +- _Params:_ + - **transaction:** object, the transaction call object which contains the following fields: + - **from:** String, the address from which the transaction is sent + - **to:** String, required, the address to which the transaction is addressed + - **gas:** String, the integer of gas provided for the transaction execution + - `gasPrice`: String, the integer of gasPrice used for each paid gas encoded as hexadecimal + - `value`: String, the integer of value sent with this transaction encoded as hexadecimal + - `data`: string, the hash of the method signature and encoded parameters. For more information, see the Contract ABI description in the [Solidity documentation](https://docs.soliditylang.org/en/latest/abi-spec.html) + - `blockNumber`: String, optional. The number of the block (in hex) from which the number of transactions is required, OR one of the following block tags: + - **latest:** the most recent block the client has available. + - **earliest:** the lowest numbered block the client has available. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_estimateGas", + "params":[{"from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155", + "to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567", + "gas": "0x76c0", + "gasPrice": "0x9184e72a000", + "value": "0x9184e72a", + "data": "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"}, + "latest" + ], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x5cec" + } + ``` +## eth_gasPrice +- _Method:_ `eth_gasPrice` + - Returns the current price per gas in wei (hexadecimal). +- _Params:_ None +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_gasPrice", + "params":[], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x3e252e0" + } + ``` +## eth_getBalance +- _Method:_ `eth_getBalance` + - Returns the balance of the account of a given address (hexadecimal). + - _Note:_ eth_getBalance only returns the balance of the native chain currency (RBTC) and does not include any ERC20 token balances for the given address. +- _Params:_ + - **Address:** String, required - 20 Bytes (type: account) + - **Block:** String: optional, either the hexadecimal value of a **blockNumber**, OR a blockHash, OR one of the following block tags: + - **Latest:** the most recent block the client has available. + - **Earliest:** the lowest numbered block the client has available. + - **Pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - if not specified, it will return the balance at the latest block available. +- Example request by `blockNumber`: + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getBalance", + "params":[ + "0x1fab9a0e24ffc209b01faa5a61ad4366982d0b7f", + "latest"], + "id":0 + }' + ``` +- Example Response: + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x2971b6b90ba793f" + } + ``` +- Example request by `blockHash`: +```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getBalance", + "params":[ + "0x1fab9a0e24ffc209b01faa5a61ad4366982d0b7f", + "0x98e7878cc686d5ca61ca2339bda064004c82a6bbf7b6d43d7674897f775edc91" + ], + "id":0 + }' + ``` + - Example Response: + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x2971b6b90ba793f" + } +``` +- Example request by `blockTag`: +```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getBalance", + "params":[ + "0x1fab9a0e24ffc209b01faa5a61ad4366982d0b7f", + "latest" + ], + "id":0 + }' + ``` + - Example Response: + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x2971b6b90ba793f" + } +``` +## eth_getBlockByHash +- _Method:_ `eth_getBlockByHash` + - Returns information about a block by `blockHash`. +- _Params:_ + - **Block:** String: required, the hash of a block. + - **Option:** Boolean, optional. + - **false:** returns only the hashes of the transactions (default) + - **true:** returns the full transactions objects +- _Returns:_ + - **object:** A block object, or null when no block was found. The returned object has the following properties: + - **number:** The block number of the requested block encoded as a hexadecimal string. null if pending. + - **hash:** The block hash of the requested block. null if pending. + - **parentHash:** Hash of the parent block. + - **sha3Uncles:** SHA3 of the uncles data in the block. + - **logsBloom:** The bloom filter for the logs of the block. null if pending. + - **transactionsRoot:** The root of the transaction trie of the block. + - **stateRoot:** The root of the final state trie of the block. + - **receiptsRoot:** The root of the receipts trie of the block. + - **miner:** The address of the beneficiary to whom the mining rewards were given. + - **difficulty:** Integer of the difficulty for this block encoded as a hexadecimal string. + - **totalDifficulty:** Integer of the total difficulty of the chain until this block encoded as a hexadecimal string. + - **extraData:** The “extra data” field of this block. + - **size:** The size of this block in bytes as an Integer value encoded as hexadecimal. + - **gasLimit:** The maximum gas allowed in this block encoded as a hexadecimal string. + - **gasUsed:** The total used gas by all transactions in this block encoded as a hexadecimal string. + - **timestamp:** The unix timestamp for when the block was collated. + - **transactions:** Array of transaction objects - please see eth_getTransactionByHash for exact shape. + - **uncles:** Array of uncle hashes. + - **minimumGasPrice:** Minimum gas price a transaction should have in order to be included in that block. + - **bitcoinMergedMiningHeader:** It is the Bitcoin block header of the block that was used for merged mining the RSK block. + - **bitcoinMergedMiningCoinbaseTransaction:** It is the coinbase transaction of the Bitcoin block that was used for merged mining the RSK block. + - **bitcoinMergedMiningMerkleProof:** It is the Merkle proof that links the Bitcoin block's Merkle root with the coinbase transaction. + - **hashForMergedMining:** It is a hash that is calculated from various fields in the RSK block header. + - **paidFees:** It represents the total amount of fees paid by all transactions included in the block. + - **cumulativeDifficulty:** It represents the total difficulty of the chain up to the current block. +- **Example Request:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getBlockByHash", + "params":[ + "0xcca8612942582f1a890231a25245174d6947b7e2e990adf74e84c035c52b104f", + false], + "id":0 + }' + ``` +- Example Response: + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": { + "number": "0xfcea", + "hash": "0xcca8612942582f1a890231a25245174d6947b7e2e990adf74e84c035c52b104f", + "parentHash": "0xb004f5597ac7eedb515079d33e5b805818fab26c269aa6094fbfea4d99845405", + "sha3Uncles": "0xff84b3163df46a90bc9414e86bfb70ddb15ecb67834eb87528f8a8abbddc23e0", + "logsBloom": "0x00000008000000800000000000000000000000000000000000000000000008000000000000040000000000000000000050000000000000000000000000000000000000000000000000000000005000000010008000000000100000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000200000000000200000000000001040000000000000400000000000000000000100000000000000010000000000000000000001000000000000001000001000000000000000000000000000020000000000080200000100000000000000000000000000000000000000000080000000000000000000000000000", + "transactionsRoot": "0x3db27be7411aed7534c14990298234782ad91e2b7964be25bb081fc014d49583", + "stateRoot": "0x1e07d7d8c5e82f40ef338816c777f5f67a445f904dbcf785647dde1bc24512ea", + "receiptsRoot": "0x11422b4b5228ed3bed9eae08bb64bbad7230e9b85ef4f74b75964d17dcdecc66", + "miner": "0x1fab9a0e24ffc209b01faa5a61ad4366982d0b7f", + "difficulty": "0x24aa8907", + "totalDifficulty": "0x4b96af092bb7", + "extraData": "0x", + "size": "0x7a5", + "gasLimit": "0x67c280", + "gasUsed": "0x0", + "timestamp": "0x5d404bf0", + "transactions": [ + "0xd63e3b6e1dd408800df812d2ab758316ac21cde155c401ae63ff9d2fff7e7710" + ], + "uncles": [ + "0xa5c66b4cd18b4d4c355528d8b3fc4f1724fea9f56ac11c4649515c4aea55bb70" + ], + "minimumGasPrice": "0x0", + "bitcoinMergedMiningHeader": + "0x00000020ec6f391bfb4fbad152de916fcf40868295b82d96533ce2329501000000000000fc38d5be8687dc934c89b3ae2a6ad3e8f77efdad192b9ceef737399fcffb1ff30c4c405df421031a441284ce", + "bitcoinMergedMiningCoinbaseTransaction": "0x0000000000000080e53dea0fdaf87e68c8b878bb8741ae72dc2d529c9604fb603d9fade1340ad3f66088ac0000000000000000266a24aa21a9ed55c19836d4dbd18acc186dae6ff453d46444df4a4ee48b6850179b871755b90d00000000000000002a6a52534b424c4f434b3a9b846df8ecbe1e7b98351144b1672c25f54207e3998ef7d8c8492a320000fcea00000000", + "bitcoinMergedMiningMerkleProof": "0x2e925b7315afc6cf5a938435ad424fa9c71c61b1c668104e34dfd30107915b7d60293a2d23038560421361d1bf29901efe8d30228d04f593c1cc991c4a5d373094588d9356998b9736912df45fb8c02c2c1228c415a5ed15b2e0dd9e14c501c40d6c398a3c6d0796b08b2d7c8e06a986e3cfc3b58b1a15073a8ef8d0ecad33d5b5d9b4d4da261ac1629892cec44816ebdc64e1d92756b554f525ff933fdfd016cab57a26339ba10486f4af5f3fdf8bf11651d5c345abb4f797c30d75252e8bf5e90e9da3aa73428dc01b7c165760eff60d0742ea243f907a7156c897a8fa29ce357a909b4933c4ea9f1744e21422550bde9e0c51064f160e7ba0b19646ca7d6d", + "hashForMergedMining": "0x9b846df8ecbe1e7b98351144b1672c25f54207e3998ef7d8c8492a320000fcea", + "paidFees": "0x0", + "cumulativeDifficulty": "0x47e89477" + } + } + + ``` +## eth_getBlockByNumber + +- _Method:_ `eth_getBlockByNumber` + - Returns information about a block by blockNumber. +- _Params:_ + - Block: String: required, either the hexadecimal value of a blockNumber, OR one of the following block tags: + - latest: the most recent block the client has available. + - earliest: the lowest numbered block the client has available. + - pending: A sample next block built by the client on top of latest and containing the set of transactions usually taken from a local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - Option: Boolean, optional. + - false: returns only the hashes of the transactions (default) + - true: returns the full transactions object +- Returns: + - object - A block object, or null when no block was found. The returned object has the following properties: + - number - The block number of the requested block encoded as a hexadecimal string. null if pending. + - hash - The block hash of the requested block. null if pending. + - parentHash - Hash of the parent block. + - sha3Uncles - SHA3 of the uncles data in the block. + - logsBloom - The bloom filter for the logs of the block. null if pending. + - transactionsRoot - The root of the transaction trie of the block. + - stateRoot - The root of the final state trie of the block. + - receiptsRoot - The root of the receipts trie of the block. + - miner - The address of the beneficiary to whom the mining rewards were given. + - difficulty - Integer of the difficulty for this block encoded as a hexadecimal string. + - totalDifficulty - Integer of the total difficulty of the chain until this block encoded as a hexadecimal string. + - extraData - The “extra data” field of this block. + - size - The size of this block in bytes as an Integer value encoded as hexadecimal. + - gasLimit - The maximum gas allowed in this block encoded as a hexadecimal string. + - gasUsed - The total used gas by all transactions in this block encoded as a hexadecimal string. + - timestamp - The unix timestamp for when the block was collated. + - transactions - Array of transaction objects - please see eth_getTransactionByHash for exact shape. + - uncles - Array of uncle hashes. + - minimumGasPrice: minimum gas price a transaction should have in order to be included in that block. + - bitcoinMergedMiningHeader: It is the Bitcoin block header of the block that was used for merged mining the RSK block. + - bitcoinMergedMiningCoinbaseTransaction: It is the coinbase transaction of the Bitcoin block that was used for merged mining the RSK block. + - bitcoinMergedMiningMerkleProof: It is the Merkle proof that links the Bitcoin block's Merkle root with the coinbase transaction. + - hashForMergedMining: It is a hash that is calculated from various fields in the RSK block header. + - paidFees: It represents the total amount of fees paid by all transactions included in the block. + - cumulativeDifficulty: It represents the total difficulty of the chain up to the current block. +- **Example Request:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getBlockByNumber", + "params":[ + "0xfcea", + false + ], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": { + "number": "0xfcea", + "hash": "0xcca8612942582f1a890231a25245174d6947b7e2e990adf74e84c035c52b104f", + "parentHash": "0xb004f5597ac7eedb515079d33e5b805818fab26c269aa6094fbfea4d99845405", + "sha3Uncles": "0xff84b3163df46a90bc9414e86bfb70ddb15ecb67834eb87528f8a8abbddc23e0", + "logsBloom": "0x00000008000000800000000000000000000000000000000000000000000008000000000000040000000000000000000050000000000000000000000000000000000000000000000000000000005000000010008000000000100000000000000000000000000200000000000000000000000000000000000000000000000000000000000000000200000000000200000000000001040000000000000400000000000000000000100000000000000010000000000000000000001000000000000001000001000000000000000000000000000020000000000080200000100000000000000000000000000000000000000000080000000000000000000000000000", + "transactionsRoot": "0x3db27be7411aed7534c14990298234782ad91e2b7964be25bb081fc014d49583", + "stateRoot": "0x1e07d7d8c5e82f40ef338816c777f5f67a445f904dbcf785647dde1bc24512ea", + "receiptsRoot": "0x11422b4b5228ed3bed9eae08bb64bbad7230e9b85ef4f74b75964d17dcdecc66", + "miner": "0x1fab9a0e24ffc209b01faa5a61ad4366982d0b7f", + "difficulty": "0x24aa8907", + "totalDifficulty": "0x4b96af092bb7", + "extraData": "0x", + "size": "0x7a5", + "gasLimit": "0x67c280", + "gasUsed": "0x0", + "timestamp": "0x5d404bf0", + "transactions": [ + "0xd63e3b6e1dd408800df812d2ab758316ac21cde155c401ae63ff9d2fff7e7710" + ], + "uncles": [ + "0xa5c66b4cd18b4d4c355528d8b3fc4f1724fea9f56ac11c4649515c4aea55bb70" + ], + "minimumGasPrice": "0x0", + "bitcoinMergedMiningHeader": + "0x00000020ec6f391bfb4fbad152de916fcf40868295b82d96533ce2329501000000000000fc38d5be8687dc934c89b3ae2a6ad3e8f77efdad192b9ceef737399fcffb1ff30c4c405df421031a441284ce", + "bitcoinMergedMiningCoinbaseTransaction": "0x0000000000000080e53dea0fdaf87e68c8b878bb8741ae72dc2d529c9604fb603d9fade1340ad3f66088ac0000000000000000266a24aa21a9ed55c19836d4dbd18acc186dae6ff453d46444df4a4ee48b6850179b871755b90d00000000000000002a6a52534b424c4f434b3a9b846df8ecbe1e7b98351144b1672c25f54207e3998ef7d8c8492a320000fcea00000000", + "bitcoinMergedMiningMerkleProof": "0x2e925b7315afc6cf5a938435ad424fa9c71c61b1c668104e34dfd30107915b7d60293a2d23038560421361d1bf29901efe8d30228d04f593c1cc991c4a5d373094588d9356998b9736912df45fb8c02c2c1228c415a5ed15b2e0dd9e14c501c40d6c398a3c6d0796b08b2d7c8e06a986e3cfc3b58b1a15073a8ef8d0ecad33d5b5d9b4d4da261ac1629892cec44816ebdc64e1d92756b554f525ff933fdfd016cab57a26339ba10486f4af5f3fdf8bf11651d5c345abb4f797c30d75252e8bf5e90e9da3aa73428dc01b7c165760eff60d0742ea243f907a7156c897a8fa29ce357a909b4933c4ea9f1744e21422550bde9e0c51064f160e7ba0b19646ca7d6d", + "hashForMergedMining": "0x9b846df8ecbe1e7b98351144b1672c25f54207e3998ef7d8c8492a320000fcea", + "paidFees": "0x0", + "cumulativeDifficulty": "0x47e89477" + } + } + ``` +## eth_getCode +- _Method:_ Returns the compiled byte code of a smart contract, if any, at a given address. +- _Params:_ + - Address: String: required, address + - Block: String, required, either the hexadecimal value of a blockNumber, OR a blockHash, OR one of the following block tags: + - latest: the most recent block the client has available. + - earliest: the lowest numbered block the client has available. + - pending: A sample next block built by the client on top of latest and containing the set of transactions usually taken from a local mempool. Intuitively, you can think of these as blocks that have not been mined yet. +- **Example Request:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getCode", + "params":[ + "0xebea27d994371cd0cb9896ae4c926bc5221f6317", + "latest" + ], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x608060405260043610610...." + } + ``` +## eth_getLogs + +- _Method:_ `eth_getLogs` + - Returns an array of all the logs matching the given filter object. +- _Params:_ + - `blockHash`: String, optional. Using blockHash is: + - is equivalent to fromBlock = toBlock = the block number with hash blockHash + - if blockHash is present in the filter criteria, then neither `fromBlock` nor `toBlock` are allowed. + - `address`: String, optional. Contract address from which logs should originate. + - `fromBlock`: String, optional. + - either the hexadecimal value of a blockNumber, OR one of the following block tags: + - **latest:** the most recent block the client has available. + - **earliest:** the lowest numbered block the client has available. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - `toBlock`: String, optional. + - either the hexadecimal value of a blockNumber, OR one of the following block tags: + - **latest:** the most recent block the client has available. + - **earliest:** the lowest numbered block the client has available. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - _topics_: Array of 32 bytes DATA topics, optional. The required topic to filter. +- _Returns:_ + - **log objects:** An array of log objects, or an empty array if nothing has changed since last poll. Log objects contain the following keys and their values: + - **logIndex:** Hexadecimal of the log index position in the block. Null when it is a pending log. + - **transactionIndex:** Hexadecimal of the transactions index position from which the log created. Null when it is a pending log. + - **transactionHash:** 32 bytes. Hash of the transactions from which this log was created. Null when it is a pending log. + - **blockHash:** 32 bytes. Hash of the block where this log was in. Null when it is a pending log. + - **blockNumber:** Block number where this log was in. Null when it is a pending log. + - **address:** 20 bytes. Address from which this log originated. + - **data:** Contains one or more 32-bytes non-indexed arguments of the log. + - **topics:** An array of 0 to 4 indexed log arguments, each 32 bytes. In solidity the first topic is the hash of the signature of the event (e.g. Deposit(address,bytes32,uint256)), except when you declared the event with the anonymous specifier. +- Constraints: + - You can make `eth_getLogs` requests on any block range with a cap of: + - 10K logs in the response + - OR a 2K block range with no cap on logs in the response + - Note that it can be filtered either by blockHash OR (fromBlock and toBlock), but not both. + - If `fromBlock`, `toBlock`, or `blockHash` are not specified, the query will return the logs corresponding to the latest block +- Example request by blockHash: + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getLogs", + "params":[ + {"blockHash": "0xcca8612942582f1a890231a25245174d6947b7e2e990adf74e84c035c52b104f"}], + "id":0 + }' + ``` +- Example Response: + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": [ + { + { + "address": "0x0000000000000000000000000000000001000008", + "blockHash": "0xcca8612942582f1a890231a25245174d6947b7e2e990adf74e84c035c52b104f", + "blockNumber": "0xfcea", + "data": "0xe6a06c82436df2ac379ed378269415c15ffda97df39ccabf71b0a9639475dd51e0778423488365", + "logIndex": "0x1", + "topics": [ + "0x000000000000000000000000000000006d696e696e675f6665655f746f706963", + "0x0000000000000000000000004495768e683423a4299d6a7f02a0689a6ff5a0a4" + ], + "transactionHash": "0xd63e3b6e1dd408800df812d2ab758316ac21cde155c401ae63ff9d2fff7e7710", + "transactionIndex": "0x0" + }, {...} }] + } + ``` +- Example request by blockHash and address: + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getLogs", + "params":[{"blockHash": "0xcca8612942582f1a890231a25245174d6947b7e2e990adf74e84c035c52b104f", + "address": "0x7f62ed5ffed1ddf15fb44632fae33f33712e31b5"}], + "id":0 + }' + ``` +- Example Response: + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": [ + { + "address": "0x7f62ed5ffed1ddf15fb44632fae33f33712e31b5", + "blockHash": "0x98e7878cc686d5ca61ca2339bda064004c82a6bbf7b6d43d7674897f775edc91", + "blockNumber": "0xf904", + "data": "0x0000000000000000000000000000000000000000000001ffe49e9e1d03940000", + "logIndex": "0x1", + "topics": [ + "0x296ba4ca62c6c21c95e828080cb8aec7481b71390585605300a8a76f9e95b527" + ], + "transactionHash": "0xb6f35548247f43a6a5c20923fe6b7bfc57242e3c3b2b39354c6d0d131527140c", + "transactionIndex": "0x0" + } + ] + } + ``` +- Example request by fromBlock, toBlock: + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getLogs", + "params":[ + { + "fromBlock": "0xfcea", + "toBlock": "0xfcea" + } + ], + "id":0 + }' + ``` +- Example Response: + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": [ + { + "address": "0x0000000000000000000000000000000001000008", + "blockHash": "0xcca8612942582f1a890231a25245174d6947b7e2e990adf74e84c035c52b104f", + "blockNumber": "0xfcea", + "data": "0xe6a06c82436df2ac379ed378269415c15ffda97df39ccabf71b0a9639475dd51e0778423488365", + "logIndex": "0x1", + "topics": [ + "0x000000000000000000000000000000006d696e696e675f6665655f746f706963", + "0x0000000000000000000000004495768e683423a4299d6a7f02a0689a6ff5a0a4" + ], + "transactionHash": "0xd63e3b6e1dd408800df812d2ab758316ac21cde155c401ae63ff9d2fff7e7710", + "transactionIndex": "0x0" + }, {...} + ] } + ``` +## eth_getStorageAt +- _Method:_ `eth_getStorageAt` + - Returns the value from a storage position at a given address. +- _Params:_ + - **Address:** String, required - A string representing the address (20 bytes) of the storage. + - **Position:** String, required - A hexadecimal code of the position in the storage. + - **Block:** String: required, either the hexadecimal value of a **blockNumber**, OR a blockHash, OR one of the following block tags: + - **Latest:** the most recent block the client has available. + - **Earliest:** the lowest numbered block the client has available. + - **Pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from a local mempool. Intuitively, you can think of these as blocks that have not been mined yet. +- Example request: + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getStorageAt", + "params":[ + "0x295a70b2de5e3953354a6a8344e616ed314d7251","0x0" + "latest"], + "id":0 + }' + ``` +- Example Response: + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x0000000000000000000000000000000000000000000000000000000000000000" + } + ``` +## eth_getTransactionByHash +- _Method:_ `eth_getTransactionByHash` + - Returns the information about a transaction requested by transaction hash. In the response object, `blockHash`, `blockNumber`, and `transactionIndex` are null when the transaction is pending. +- _Params:_ + - `transactionHash`: String, required - A string representing the hash (32 bytes) of a transaction. +- **Returns:** + - A transaction object, or null when no transaction was found. The transaction object will consist of the following keys and their values: - + - `blockHash`: 32 bytes. A hash of the block including this transaction. null when it's pending. + - `blockNumber`: The number of the block including this transaction. null when it's pending. + - `from`: 20 bytes. The address of the sender. + - `to`: 20 bytes. The address of the receiver. null when it's a contract creation transaction. + - `gas`: Gas provided by the sender. + - `gasPrice`: Gas price provided by the sender in Wei. + - `hash`: 32 bytes. The hash of the transaction. + - `input`: The data sent along with the transaction. + - `nonce`: The number of transactions made by the sender prior to this one. + - `v`: The ECDSA recovery ID. + - `r`: 32 bytes. The ECDSA signature r. + - `s`: 32 bytes. The ECDSA signature s. + - `transactionIndex`: The transaction's index position in the block, in hexadecimal. null when it's pending. + - `type`: The transaction type. + - `value`: The value transferred in Wei. +- **Example Request:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getTransactionByHash", + "params":["0x359f6010957a25b885387e3201c9262c71f91e47ff487c49e5168a54fc8ea110"], + "id":0 + }' + ``` +- Example Response: + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": [ + { + "hash": "0x359f6010957a25b885387e3201c9262c71f91e47ff487c49e5168a54fc8ea110", + "nonce": "0x10", + "blockHash": "0xf0b093db64e06ff6b94cd3cfc06d85d3664d7b021bef36c4471475b4f1d8b2b9", + "blockNumber": "0x35aa", + "transactionIndex": "0x0", + "from": "0x3843d583b0f087ec7e3476c3495e52dbde5280b3", + "to": "0x052ef40ccda2d51ca3d49cc3d6007b25965bec5b", + "gas": "0x20cfb", + "gasPrice": "0x387ee40", + "value": "0x0", + "input": "0xcc6ebc8b00000000000000000000000000", + "v": "0x62", + "r": "0x1f8bb5859d8194eebfb781ed6d12de95d44b66ecf", + "s": "0x4a98b84d16a534681c5a639318b1ceffe967ce751458f51", + "type": "0x0" + } + ] + } + ``` +## eth_getTransactionCount +- _Method:_ `eth_getTransactionCount` + - Returns the number of transactions sent from an address. +- **Params:** + - _Address_: String, required - 20 Bytes + - _Block_: String: optional, either the hexadecimal value of a `blockNumber`, OR a `blockHash`, OR one of the following block tags: + - `latest`: the most recent block the client has available. + - `earliest`: the lowest numbered block the client has available. + - `pending`: A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - if not specified, it will return the balance at the latest block available. +- **Returns:** + - **transaction count:** A hexadecimal equivalent of the integer representing the number of transactions sent from the given address. +- **Example Request:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getTransactionCount", + "params":["0x4495768e683423a4299d6a7f02a0689a6ff5a0a4", "latest"], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x9856" + } + ``` +## eth_getTransactionReceipt +- _Method:_ `eth_getTransactionReceipt` + - Returns the receipt of a transaction given transaction hash. Note that the receipt is not available for pending transactions. + - _Params:_ + - `transactionHash`: String, required. A string representing the hash (32 bytes) of a transaction. +- Returns: + - A transaction receipt object, or null when no receipt was found. The transaction receipt object will contain the following keys and their values: + - `blockHash`: 32 bytes. Hash of the block including this transaction. + - `blockNumber`: Block number including this transaction. + - `contractAddress`: 20 bytes. The contract address created if the transaction was a contract creation, otherwise null. + - `cumulativeGasUsed`: The total amount of gas used when this transaction was executed in the block. + - `effectiveGasPrice`: The actual value per gas deducted from the sender's account. Before EIP-1559, equal to the gas price. + - `from`: 20 bytes. The address of the sender. + - `gasUsed`: The amount of gas used by this specific transaction alone. + - `logs`: (Array) An array of log objects generated by this transaction. + - `logsBloom`: 256 bytes. Bloom filter for light clients to quickly retrieve related logs. + - One of the following: + - `root`: 32 bytes of post-transaction stateroot (pre-Byzantium) + - `status`: Either 1 (success) or 0 (failure) + - `to`: 20 bytes. The address of the receiver. null when the transaction is a contract creation transaction. + - `transactionHash`: 32 bytes. The hash of the transaction. + - `transactionIndex`: Hexadecimal of the transaction's index position in the block. + - `type`: the transaction type. +- **Example Request:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getTransactionReceipt", + "params":[ + "0x359f6010957a25b885387e3201c9262c71f91e47ff487c49e5168a54fc8ea110" + ], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": { + "transactionHash": "0x359f6010957a25b885387e3201c9262c71f91e47ff487c49e5168a54fc8ea110", + "transactionIndex": "0x0", + "blockHash": "0xf0b093db64e06ff6b94cd3cfc06d85d3664d7b021bef36c4471475b4f1d8b2b9", + "blockNumber": "0x35aa", + "cumulativeGasUsed": "0x15efc", + "gasUsed": "0x15efc", + "contractAddress": null, + "logs": [], + "from": "0x3843d583b0f087ec7e3476c3495e52dbde5280b3", + "to": "0x052ef40ccda2d51ca3d49cc3d6007b25965bec5b", + "status": "0x1", + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "type": "0x0" + } + } + ``` +## eth_getBlockTransactionCountByHash +- _Method:_ `eth_getBlockTransactionCountByHash` + - Returns the number of transactions for the block matching the given block hash (in hex). +- _Params:_ + - `blockHash`: String, required. The hash of the block from which the number of transactions is required. +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getBlockTransactionCountByHash", + "params":[" + 0xf0b093db64e06ff6b94cd3cfc06d85d3664d7b021bef36c4471475b4f1d8b2b9"], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x2" + } + ``` +## eth_getBlockTransactionCountByNumber +- _Method:_ `eth_getBlockTransactionCountByNumber` + - Returns the number of transactions for the block matching the given block number (in hex). +- _Params:_ + - `blockNumber`: String, required. The number of the block (in hex) from which the number of transactions is required, OR one of the following block tags: + - **latest:** the most recent block the client has available. + - **earliest:** the lowest numbered block the client has available. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. +- **Example** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getBlockTransactionCountByNumber", + "params":["0xfcea"], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x1" + } + ``` +## eth_getTransactionByBlockHashAndIndex +- _Method:_ `eth_getTransactionByBlockHashAndIndex` + - Returns information about a transaction for a specific block and transaction index position. +- _Params:_ + - blockHash: String, required. The hash of the block in which the transaction is recorded. + - index: String, required. The position number of the transaction (in Hex). +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getTransactionByBlockHashAndIndex", + "params":[ + "0x1e3566b5fe1109d0054e43cf169f9aa4484aba61fc83fe6799d2271bab725d36", + "0x0" + ], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": { + "_id": "6528a2bdc44af7001f969f62", + "hash": "0x7188161bc67e8c19031bfa1732a8e74f32921b45fa3762e5451122459c5fe135", + "nonce": "0x37a", + "blockHash": "0x1e3566b5fe1109d0054e43cf169f9aa4484aba61fc83fe6799d2271bab725d36", + "blockNumber": "0x35c7", + "transactionIndex": "0x0", + "from": "0x9a3bfdea2245738dd5f25453d13742350a4f1c6e", + "to": "0x0000000000000000000000000000000001000006", + "gas": "0x0", + "gasPrice": "0x0", + "value": "0x0", + "input": "0xe5400e7b00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000500000ff3feef74a17227d680e1bc4117b4207f8b101f132f5da9c9abf8699d590000000006708c984514a47f5d4781d31ce2761392b41254374f636ab3bf3f838f40f28cccf27265d531d041a40bd27d900000000000000000000000000000000", + "v": "0x61", + "r": "0xfdb6ea619ca1fbb42e8f8976209ec0f617b7068e7e89cceae2dc33492eab92af", + "s": "0x8b2a4279058793069d74b9e1d5e71747120ba90bbfa99d99215a55c5020b47", + "type": "0x0" + } + } + ``` +## eth_getTransactionByBlockNumberAndIndex +- _Method:_ `eth_getTransactionByBlockNumberAndIndex` + - Returns information about a transaction for a specific block and transaction index position. +- _Params:_ + - `blockNumber`: String, required. The number of the block (in hex) from which the number of transactions is required, OR one of the following block tags: + - **latest:** the most recent block the client has available. + - **earliest:** the lowest numbered block the client has available. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. + - **index:** String, required. The position number of the transaction (in Hex). +- Example: + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getTransactionByBlockNumberAndIndex", + "params":[ + "0x35c7", + "0x0" + ], + "id":0 + }' + ``` +- Example Response: + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": { + "_id": "6528a2bdc44af7001f969f62", + "hash": "0x7188161bc67e8c19031bfa1732a8e74f32921b45fa3762e5451122459c5fe135", + "nonce": "0x37a", + "blockHash": "0x1e3566b5fe1109d0054e43cf169f9aa4484aba61fc83fe6799d2271bab725d36", + "blockNumber": "0x35c7", + "transactionIndex": "0x0", + "from": "0x9a3bfdea2245738dd5f25453d13742350a4f1c6e", + "to": "0x0000000000000000000000000000000001000006", + "gas": "0x0", + "gasPrice": "0x0", + "value": "0x0", + "input": "0xe5400e7b00000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000500000ff3feef74a17227d680e1bc4117b4207f8b101f132f5da9c9abf8699d590000000006708c984514a47f5d4781d31ce2761392b41254374f636ab3bf3f838f40f28cccf27265d531d041a40bd27d900000000000000000000000000000000", + "v": "0x61", + "r": "0xfdb6ea619ca1fbb42e8f8976209ec0f617b7068e7e89cceae2dc33492eab92af", + "s": "0x8b2a4279058793069d74b9e1d5e71747120ba90bbfa99d99215a55c5020b47", + "type": "0x0" + } + } + ``` +## eth_getUncleCountByBlockHash +- _Method:_ `eth_getUncleCountByBlockHash` + - Returns the number of uncles for the block matching the given block hash (in hex). +- _Params:_ + - `blockHash`: String, required. The hash of the block from which the number of uncles is required. +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getUncleCountByBlockHash", + "params":[ + "0xf0b093db64e06ff6b94cd3cfc06d85d3664d7b021bef36c4471475b4f1d8b2b9" + ], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x3" + } + ``` +## eth_getUncleCountByBlockNumber +- _Method:_ `eth_getUncleCountByBlockNumber` + - Returns the number of uncles for the block matching the given block number (in hex). +- _Params:_ + - `blockNumber`: String, required. The number of the block (in hex) from which the number of transactions is required, OR one of the following block tags: + - **latest:** the most recent block the client has available. + - **earliest:** the lowest numbered block the client has available. + - **pending:** A sample next block built by the client on top of latest and containing the set of transactions usually taken from local mempool. Intuitively, you can think of these as blocks that have not been mined yet. +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_getUncleCountByBlockNumber", + "params":[ + "0x35aa" + ], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x3" + } + ``` +## eth_protocolVersion +- _Method:_ `eth_protocolVersion` + - Returns the current protocol version. +- _Params:_ None +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_protocolVersion", + "params":[], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x3e" + } + ``` +## eth_sendRawTransaction +- _Method:_ `eth_sendRawTransaction` + - Creates a new message call transaction or a contract creation for signed transactions. +- _Response:_ The transaction hash, or the zero hash if the transaction is not yet available. +- _Params:_ + - `transactionData`: Required, the signed transaction data (typically signed with a library, using your private key). Use `eth_getTransactionReceipt` to get the contract address, after the transaction was mined, when you created a contract. +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"eth_estimateGas", + "params":[ + "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675" + ], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x359f6010957a25b885387e3201c9262c71f91e47ff487c49e5168a54fc8ea110" + } + ``` +## net_version +- _Method:_ `net_version` + - Returns the number of the network, in decimal value. +- _Params:_ None +- **Responses:** + - `31` -> Rootstock Testnet + - `30` -> Rootstock Mainnet +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"net_version", + "params":[], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "31" + } + ``` +## web3_clientVersion +- _Method:_ `web3_clientVersion` + - Returns the current client version. +- _Params:_ None +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"web3_clientVersion", + "params":[], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "RskJ/6.2.0/Linux/Java1.8/ARROWHEAD-45eb751" + } + ``` +## web3_sha3 +- _Method:_ `web3_sha3` + - Returns Keccak-256 (not the standardized SHA3-256) hash of the given data. +- _Params:_ + - `data`: Required, string: The data in hexadecimal form to convert into a SHA3 hash +- **Example:** + ```shell + curl --location 'https://rpc.testnet.rootstock.io/' \ + --request POST \ + --header 'accept: application/json' \ + --header 'Content-Type: application/json' \ + --data '{ + "jsonrpc":"2.0", + "method":"web3_sha3", + "params":["0x68656c6c6f20776f726c64"], + "id":0 + }' + ``` +- **Example Response:** + ```shell + { + "jsonrpc": "2.0", + "id": 0, + "result": "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad" + } + ``` diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/07-rpc-api/_category_.yml b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/07-rpc-api/_category_.yml new file mode 100644 index 00000000..1b01beb2 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/07-rpc-api/_category_.yml @@ -0,0 +1,5 @@ +label: API RPC +position: 5 +link: + type: índice-generado + slug: /desarrolladores/rpc-api/ diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/08-libraries/01-rsk-precompiled-abis/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/08-libraries/01-rsk-precompiled-abis/index.md new file mode 100644 index 00000000..01b69757 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/08-libraries/01-rsk-precompiled-abis/index.md @@ -0,0 +1,86 @@ +--- +title: ABI precompiladas +tags: + - bibliotecas + - abi + - precompilado +sidebar_label: ABI precompiladas +sidebar_position: 100 +description: ABI precompiladas. +--- + +Aquí encontrarás las ABIs para los contratos precompilados existentes en Rootstock. También obtendrás sus direcciones y un constructor para utilizarlo con web3.js. + +## Versiones + +Para las distintas versiones de Rootstock se necesitan versiones diferentes del paquete mencionado. + +El versionado semántico de este paquete no se correlaciona con el versionado semántico de Rootstock. Para cada versión con nombre del nodo RSKj, habrá una versión con nombre correspondiente en npm. + +El soporte de este paquete comienza con `ORCHID`. + +## Utilización + +Para la instalación de estos paquetes debe ejecutar en una ventana de terminal: + +```shell +npm install @rsksmart/rsk-precompiled-abis@ +``` + +Como ejemplo para definirlo y utilizarlo: + +1. Incluye el paquete Web3. + +```javascript +const Web3 = require('web3'); +``` + +2. Incluye el paquete `rsk-precompiled-abis`. + +```javascript +const precompiled = require('@rsksmart/rsk-precompiled-abis'); +``` + +3. Crea una instancia del contrato utilizando el método build del paquete y Web3 como parámetro. + +(es decir: utilizando el Puente) + +```shell +var bridge = precompiled.bridge.build(new Web3('http://localhost:4444')); +``` + +4. Utiliza un método del contrato. Por ejemplo, aquí llamamos a `getFederationAddress`, y muestra su resultado en la consola. + +```shell +bridge.methods.getFederationAddress().call().then(console.log); +``` + +:::note[Important] +Si la versión a instalar no está definida en la línea de comandos, la versión corresponderá a la última versión en [rskj releases page](https://github.com/rsksmart/reproducible-builds/tree/master/rskj). +::: + +## Tabla de versiones + +| Versión del paquete | Versión portainjertos | +| ------------------------------------------------------ | ------------------------------------------------ | +| 1.0.0-ORCHID | ORCHID-0.6.2 | +| 2.0.0-WASABI | WASABI-1.0.0 | +| 2.0.1-WASABI | WASABI-1.0.0 | +| 3.0.0-PAPYRUS | PAPYRUS-2.0.0 | +| 3.0.0-PAPYRUS | PAPYRUS-2.2.0 | +| 3.0.0-IRIS | IRIS-3.0.0 | +| 3.1.0-IRIS | IRIS-3.1.0 | +| 3.2.0-IRIS | IRIS-3.2.0 | +| 3.3.0-IRIS | IRIS-3.3.0 | +| 4.0.0-HOP | HOP-4.0.0 | +| 4.1.0-HOP | HOP-4.1.0 | +| 4.1.1-HOP | HOP-4.1.1 | +| 4.2.0-HOP | HOP-4.2.0 | +| 4.3.0-HOP | HOP-4.3.0 | +| 4.4.0-HOP | HOP-4.4.0 | +| 5.0.0-fingerroot | FINGERROOT-5.0.0 | +| 5.1.0-fingerroot | FINGERROOT-5.1.0 | +| 5.2.0-fingerroot | FINGERROOT-5.2.0 | +| 5.3.0-fingerroot | FINGERROOT-5.3.0 | +| 5.4.0-fingerroot | FINGERROOT-5.4.0 | +| 6.0.0-CABEZA DE FLECHA | FLECHA-6.0.0 | diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/08-libraries/_category_.yml b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/08-libraries/_category_.yml new file mode 100644 index 00000000..a2c1c18d --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/08-libraries/_category_.yml @@ -0,0 +1,5 @@ +label: Bibliotecas +position: 8 +link: + type: índice-generado + slug: /desarrolladores/bibliotecas/ diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/08-libraries/rif-wallet-libs.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/08-libraries/rif-wallet-libs.md new file mode 100644 index 00000000..2f6d2db4 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/08-libraries/rif-wallet-libs.md @@ -0,0 +1,63 @@ +--- +title: Bibliotecas monedero RIF +tags: + - monedero rif + - rif + - portainjertos + - cartera + - bibliotecas +sidebar_label: Bibliotecas monedero RIF +sidebar_position: 200 +description: RIF Wallet es un monedero de contratos inteligentes de código abierto que permite a las empresas crear y desplegar monederos en cadena totalmente personalizables. +--- + +Las Bibliotecas RIF Wallet contienen un conjunto de paquetes utilizados por RIF Wallet. Puede instalar las Bibliotecas RIF Wallet directamente desde dentro de la aplicación. Para obtener más información, visite [RIF Wallet Lib Repo](https://github.com/rsksmart/rif-wallet-libs?tab=readme-ov-file#packages). + +## Paquetes + +### Núcleo de la cartera RIF + +El [RIF Wallet Core](https://www.npmjs.com/package/@rsksmart/rif-wallet-core) es la librería wallet que conecta la UI con el RIF Relay SDK. Esta clase acepta un Ethers Signer que maneja la mayoría de los métodos criptográficos, como crear una Cartera, firmar tx o mensaje, estimar gas, enviar transacciones y desplegar las carteras inteligentes. + +La función `onRequest` es donde la UX maneja la transacción o interacción. Se envía una transacción a RIFWallet y se pasa al método onRequest. En este punto, la UX puede pedir al usuario que haga clic en "aceptar" o "negar". Esto significa que el monedero puede ser inyectado en WalletConnect, e injectedBrowser o utilizado a través de la UX y cuando llega una transacción, siempre pedirá al usuario que acepte o rechace la acción. + +Consulte el [README](https://www.npmjs.com/package/@rsksmart/rif-wallet-core) para obtener más información. + +### Cartera RIF Potenciador ABI + +El paquete [ABI Enhancer](https://www.npmjs.com/package/@rsksmart/rif-wallet-abi-enhancer) intenta decodificar una transacción a un formato legible por humanos. Existen diferentes estrategias de descodificación: + +- Transacción rBTC - donde los datos son 0x y la transacción es el envío de gas de una cuenta a otra. +- Transacción ERC20 (y variantes) - envío de un token de un usuario a otro. En este caso, el destinatario y el importe se encuentran en el campo de datos. +- Otra transacción - Una interacción de llamada de contrato. En este caso, consulta la lista pública disponible de tipos de métodos conocidos e intenta descodificarla. En este caso, los detalles de la transacción no se transforman. + +Consulte más información en [README](https://www.npmjs.com/package/@rsksmart/rif-wallet-abi-enhancer). + +### Sistema de gestión de claves + +La biblioteca [RIF Wallet Key Management System](https://www.npmjs.com/package/@rsksmart/rif-wallet-kms). + +### Biblioteca Bitcoin + +RIF Wallet [Bitcoin Library](https://www.npmjs.com/package/@rsksmart/rif-wallet-bitcoin) es una librería para manejar la recepción y envío de bitcoin en React Native. +Ver Configuración básica y Cómo usar en el [RIF Wallet Bitcoin README](https://www.npmjs.com/package/@rsksmart/rif-wallet-bitcoin). + +### SDK de cliente de retransmisión RIF + +Este `rif-relay-light-sdk` es una [implementación ligera](https://www.npmjs.com/package/@rsksmart/rif-relay-light-sdk) del cliente RIF Relay SDK construido usando éteres y utilizado en RIF Wallet. + +Consulte Configuración básica, cómo desplegar el monedero inteligente y cómo estimar y retransmitir una transacción en el [README](https://www.npmjs.com/package/@rsksmart/rif-relay-light-sdk). + +### Ficha de cartera RIF + +El paquete [RIF Wallet Token](https://www.npmjs.com/package/@rsksmart/rif-wallet-token) contiene clases simples para activos/tokens ERC20, ERC677 y rBTC. Incluye la ABI para ERC20 y ERC677. + +### Cartera RIF EIP681 + +El [RIF Wallet EIP681](https://npmjs.com/package/@rsksmart/rif-wallet-eip681) es una implementación básica e incompleta de [EIP681, Formato URL para solicitudes de transacciones](https://npmjs.com/package/@rsksmart/rif-wallet-eip681). + +Consulte el [README](https://npmjs.com/package/@rsksmart/rif-wallet-eip681) para obtener más información. + +### Servicios de monedero RIF + +Esta librería [RIF Wallet Services](https://www.npmjs.com/package/@rsksmart/rif-wallet-services) es responsable de mapear todos los endpoints disponibles y realizar la conexión socket en rif-wallet-services (backend). diff --git a/i18n/es/docusaurus-plugin-content-docs/current/02-developers/index.md b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/index.md new file mode 100644 index 00000000..a54f85a2 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/02-developers/index.md @@ -0,0 +1,36 @@ +--- +sidebar_position: 1 +title: Panorama de los desarrolladores +sidebar_label: Visión general +tags: + - rsk + - portainjertos + - desarrolladores + - web3 + - kits de inicio + - contratos inteligentes + - how-tos +description: Aproveche su conocimiento existente de Solidity y herramientas como Rust, Hardhat y Wagmi para implementar y escalar sus dApps en la solución pionera de capa 2 que combina lo mejor de la seguridad de Bitcoin y las capacidades de Ethereum Smart Contract. +--- + +Bienvenido a la sección de información general para desarrolladores de Rootstock. + +Esta sección permite a los desarrolladores iniciarse en la blockchain de Rootstock. Los desarrolladores pueden instalar un entorno de desarrollo local utilizando Hardhat, etc., crear y probar contratos con las bibliotecas proporcionadas y utilizar las bibliotecas para crear aplicaciones descentralizadas. + +:::info\[Info] + +- ¿Quieres probar rápidamente tu dApp en testnet antes de desplegarla en mainnet? Utilice la [API RPC](https://rpc.rootstock.io/) o consulte los [métodos json-rpc](/developers/rpc-api/methods/) disponibles en la API RPC. +- Sumérgete de lleno con [guías paso a paso](/developers/quickstart/) para configurar tu entorno de desarrollo y desplegar tu primera dApp. + ::: + +## Navegar por la sección de desarrolladores + +| Recursos | Descripción | +| -------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | +| [Requisitos de hardware](/developers/requirements/) | Configure su entorno local. | +| [Blockchain Essentials](/desarrolladores/blockchain-essentials/) | Fundamentos de la cadena de bloques Rootstock. | +| [Inicio rápido](/developers/quickstart/) | Sumérgete de lleno en las guías paso a paso para configurar tu entorno de desarrollo y desplegar tu primera dApp. | +| [Desarrollo de contratos inteligentes](/developers/smart-contracts/) | Explore recursos detallados sobre la creación de contratos inteligentes seguros y escalables en Rootstock. | +| [Guías de integración](/developers/integrate/) | Profundice sus conocimientos con guías detalladas y tutoriales informativos que cubren diversos aspectos del desarrollo de Rootstock. | +| [JSON-RPC](/desarrolladores/rpc-api/setup/) | Pruebe sus dApps en testnet en cuestión de minutos antes de desplegarlas en mainnet mediante la API RPC. | +| [Bibliotecas](/desarrolladores/bibliotecas/) | Acceda a herramientas y bibliotecas esenciales para agilizar su proceso de desarrollo. | diff --git a/i18n/es/docusaurus-plugin-content-docs/current/04-resources/01-courses/index.md b/i18n/es/docusaurus-plugin-content-docs/current/04-resources/01-courses/index.md new file mode 100644 index 00000000..d7f223c2 --- /dev/null +++ b/i18n/es/docusaurus-plugin-content-docs/current/04-resources/01-courses/index.md @@ -0,0 +1,32 @@ +--- +sidebar_label: Cursos sobre portainjertos +sidebar_position: 2 +title: Cursos sobre portainjertos +tags: + - rsk + - preguntas frecuentes + - ayuda + - soporte + - curso + - portainjertos + - programa de embajadores +description: Bienvenido a los cursos de Rootstock; Explore los materiales de aprendizaje y los cursos que le permitirán iniciarse en la construcción con Rootstock y RIF Technologies. +--- + +Explore el material didáctico y los cursos que le permitirán empezar a trabajar con Rootstock y RIF Technologies. + + + +

+ + diff --git a/package.json b/package.json index 3b60c44a..db89c447 100644 --- a/package.json +++ b/package.json @@ -8,6 +8,7 @@ "scripts": { "docusaurus": "docusaurus", "start": "docusaurus start", + "start:es": "docusaurus start --locale es", "build": "docusaurus build", "swizzle": "docusaurus swizzle", "deploy": "docusaurus deploy",