diff --git a/.github/ISSUE_TEMPLATE/suggest_dapp.yaml b/.github/ISSUE_TEMPLATE/suggest_dapp.yaml index 8e0df30c748..960b3df2137 100644 --- a/.github/ISSUE_TEMPLATE/suggest_dapp.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_dapp.yaml @@ -6,7 +6,7 @@ body: - type: markdown attributes: value: | - Before suggesting a dapp, make sure you've read [our listing policy](https://www.ethereum.org/en/contributing/adding-products/). + Before suggesting a dapp, make sure you've read [our listing policy](https://www.ethereum.org/contributing/adding-products/). - type: markdown attributes: value: Only continue with the issue if your dapp meets the criteria listed there. diff --git a/.github/ISSUE_TEMPLATE/suggest_dev_tool.yaml b/.github/ISSUE_TEMPLATE/suggest_dev_tool.yaml index a566cf17055..5c2e6bb1658 100644 --- a/.github/ISSUE_TEMPLATE/suggest_dev_tool.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_dev_tool.yaml @@ -6,7 +6,7 @@ body: - type: markdown attributes: value: | - Before submitting this suggestion, be sure to read our [listing policy for dev tools](https://ethereum.org/en/contributing/adding-developer-tools/) + Before submitting this suggestion, be sure to read our [listing policy for dev tools](https://ethereum.org/contributing/adding-developer-tools/) - type: markdown id: project_info attributes: diff --git a/.github/ISSUE_TEMPLATE/suggest_exchange.yaml b/.github/ISSUE_TEMPLATE/suggest_exchange.yaml index 60e4e670c6c..9b38b858c3d 100644 --- a/.github/ISSUE_TEMPLATE/suggest_exchange.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_exchange.yaml @@ -6,7 +6,7 @@ body: - type: markdown attributes: value: | - Before suggesting an exchange, make sure you've read [our exchange listing policy](https://ethereum.org/en/contributing/adding-exchanges/). If it's a decentralized exchange (DEX) you'd like to list, please take a look at our [policy for listing dapps](https://ethereum.org/en/contributing/adding-products/). + Before suggesting an exchange, make sure you've read [our exchange listing policy](https://ethereum.org/contributing/adding-exchanges/). If it's a decentralized exchange (DEX) you'd like to list, please take a look at our [policy for listing dapps](https://ethereum.org/contributing/adding-products/). - type: markdown attributes: value: | diff --git a/.github/ISSUE_TEMPLATE/suggest_layer2.yaml b/.github/ISSUE_TEMPLATE/suggest_layer2.yaml index 23e0c6afffc..46dd1c259b2 100644 --- a/.github/ISSUE_TEMPLATE/suggest_layer2.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_layer2.yaml @@ -6,7 +6,7 @@ body: - type: markdown attributes: value: | - Before suggesting a layer 2, make sure you've read [our listing policy](https://ethereum.org/en/contributing/adding-layer-2s/). + Before suggesting a layer 2, make sure you've read [our listing policy](https://ethereum.org/contributing/adding-layer-2s/). - type: markdown attributes: value: | diff --git a/.github/ISSUE_TEMPLATE/suggest_quiz.yaml b/.github/ISSUE_TEMPLATE/suggest_quiz.yaml index af037b47770..51583f91849 100644 --- a/.github/ISSUE_TEMPLATE/suggest_quiz.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_quiz.yaml @@ -6,7 +6,7 @@ body: - type: markdown attributes: value: | - Before suggesting additions, updates, or deletions of quiz content, make sure you've read our [contributing guidelines for quizzes](https://ethereum.org/en/contributing/quizzes/). + Before suggesting additions, updates, or deletions of quiz content, make sure you've read our [contributing guidelines for quizzes](https://ethereum.org/contributing/quizzes/). - type: input id: page attributes: diff --git a/.github/ISSUE_TEMPLATE/suggest_resource.yaml b/.github/ISSUE_TEMPLATE/suggest_resource.yaml index 6df8803f163..6fab6bd9b74 100644 --- a/.github/ISSUE_TEMPLATE/suggest_resource.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_resource.yaml @@ -6,7 +6,7 @@ body: - type: markdown attributes: value: | - Before suggesting a resource, make sure you've read [our listing policy](https://www.ethereum.org/en/contributing/adding-resources/). + Before suggesting a resource, make sure you've read [our listing policy](https://www.ethereum.org/contributing/adding-resources/). - type: markdown attributes: value: Only continue with the issue if your resource meets the criteria listed there. diff --git a/.github/ISSUE_TEMPLATE/suggest_staking_product.yaml b/.github/ISSUE_TEMPLATE/suggest_staking_product.yaml index 2cf09f2ba93..b8dd89cb28d 100644 --- a/.github/ISSUE_TEMPLATE/suggest_staking_product.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_staking_product.yaml @@ -6,7 +6,7 @@ body: - type: markdown attributes: value: | - Before suggesting a staking product or service, make sure you've read [our listing policy](https://ethereum.org/en/contributing/adding-staking-products/). + Before suggesting a staking product or service, make sure you've read [our listing policy](https://ethereum.org/contributing/adding-staking-products/). - type: markdown attributes: value: | diff --git a/.github/ISSUE_TEMPLATE/suggest_tutorial.yaml b/.github/ISSUE_TEMPLATE/suggest_tutorial.yaml index 43c3a3174fc..7877a4d6864 100644 --- a/.github/ISSUE_TEMPLATE/suggest_tutorial.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_tutorial.yaml @@ -6,7 +6,7 @@ body: - type: markdown attributes: value: | - We'll consider [our content resources policy](https://ethereum.org/en/contributing/content-resources/) when reviewing the tutorial, so please take a look there first. + We'll consider [our content resources policy](https://ethereum.org/contributing/content-resources/) when reviewing the tutorial, so please take a look there first. - type: markdown id: tutorial_info attributes: @@ -29,7 +29,7 @@ body: id: tutorial_tags attributes: label: Tutorial tags - description: What topics are covered in your tutorial? Check out the current tags on https://ethereum.org/en/developers/tutorials/ but feel free to add new ones + description: What topics are covered in your tutorial? Check out the current tags on https://ethereum.org/developers/tutorials/ but feel free to add new ones validations: required: true - type: dropdown diff --git a/.github/ISSUE_TEMPLATE/suggest_wallet.yaml b/.github/ISSUE_TEMPLATE/suggest_wallet.yaml index 1f356b336e1..a96fd28b810 100644 --- a/.github/ISSUE_TEMPLATE/suggest_wallet.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_wallet.yaml @@ -6,7 +6,7 @@ body: - type: markdown attributes: value: | - Before suggesting a wallet, make sure you've read [our listing policy](https://www.ethereum.org/en/contributing/adding-wallets/). Only continue with the issue if the wallet meets the criteria listed there. For any required questions, please answer N/A for any questions not applicable to your wallet. This form is very comprehensive, and if you feel like you can't answer all the questions, please reach out to the wallet provider to fill out this template. + Before suggesting a wallet, make sure you've read [our listing policy](https://www.ethereum.org/contributing/adding-wallets/). Only continue with the issue if the wallet meets the criteria listed there. For any required questions, please answer N/A for any questions not applicable to your wallet. This form is very comprehensive, and if you feel like you can't answer all the questions, please reach out to the wallet provider to fill out this template. - type: markdown id: project_info attributes: diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8fed45a889b..87a57e13fe3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -5,4 +5,4 @@ ### Thank you for your interest in contributing! -Please see [our contributing guide on ethereum.org](https://ethereum.org/en/contributing/) and [our GitHub repo homepage](https://github.com/ethereum/ethereum-org-website#how-to-contribute) for the latest information on how to contribute! +Please see [our contributing guide on ethereum.org](https://ethereum.org/contributing/) and [our GitHub repo homepage](https://github.com/ethereum/ethereum-org-website#how-to-contribute) for the latest information on how to contribute! diff --git a/README.md b/README.md index 8b9488f4e26..4d2c9860909 100644 --- a/README.md +++ b/README.md @@ -10,13 +10,13 @@

👋 Welcome to ethereum.org!

-This is the repo for the [ethereum.org](https://ethereum.org) website, a resource for the Ethereum community. The site's purpose is to _“Be the best portal to Ethereum for our growing global community"_ - read more about what this means [here](https://ethereum.org/en/about/). +This is the repo for the [ethereum.org](https://ethereum.org) website, a resource for the Ethereum community. The site's purpose is to _“Be the best portal to Ethereum for our growing global community"_ - read more about what this means [here](https://ethereum.org/about/). -[ethereum.org](https://ethereum.org) is being improved and changed over time through the contributions of community members who submit content, give feedback, or volunteer their time to manage its evolution. If you’re interested in helping to improve [ethereum.org](https://ethereum.org), find out [how to contribute](https://ethereum.org/en/contributing/). +[ethereum.org](https://ethereum.org) is being improved and changed over time through the contributions of community members who submit content, give feedback, or volunteer their time to manage its evolution. If you’re interested in helping to improve [ethereum.org](https://ethereum.org), find out [how to contribute](https://ethereum.org/contributing/). ## Looking for the Ethereum blockchain's code? -If you're looking for the Ethereum blockchain itself, there is no single repo. Instead, Ethereum has multiple implementations of the protocol written in different programming languages for security and diversity. [Check out the different implementations](https://ethereum.org/en/developers/docs/nodes-and-clients/#execution-clients) +If you're looking for the Ethereum blockchain itself, there is no single repo. Instead, Ethereum has multiple implementations of the protocol written in different programming languages for security and diversity. [Check out the different implementations](https://ethereum.org/developers/docs/nodes-and-clients/#execution-clients)
@@ -163,7 +163,7 @@ git push ### 6. Wait for review - The website team reviews every PR -- See [how decisions are made on content changes](https://ethereum.org/en/contributing/#how-decisions-about-the-site-are-made) +- See [how decisions are made on content changes](https://ethereum.org/contributing/#how-decisions-about-the-site-are-made) - Acceptable PRs will be approved & merged into the `dev` branch Learn more about how we review pull requests [here](docs/review-process.md). @@ -206,7 +206,7 @@ Learn more about how we review pull requests [here](docs/review-process.md). - To help with verification we request GitHub contributors connect their GitHub account with their Discord account (Discord > Settings > Connections > GitHub). Crowdin contributors will be verified directly through Crowdin by our team. -If you haven't contributed yet and would like to earn a POAP/OATs to show your loyalty to the Ethereum space, head over to the [issues](https://github.com/ethereum/ethereum-org-website/issues/) tab to get started! If you would like to contribute to translations check out our [Translation Program](https://ethereum.org/en/contributing/translation-program/). +If you haven't contributed yet and would like to earn a POAP/OATs to show your loyalty to the Ethereum space, head over to the [issues](https://github.com/ethereum/ethereum-org-website/issues/) tab to get started! If you would like to contribute to translations check out our [Translation Program](https://ethereum.org/contributing/translation-program/).
diff --git a/app/[locale]/10years/_components/NFTMintCard/views/MintAlreadyMinted.tsx b/app/[locale]/10years/_components/NFTMintCard/views/MintAlreadyMinted.tsx index 8de1889d247..243a546637e 100644 --- a/app/[locale]/10years/_components/NFTMintCard/views/MintAlreadyMinted.tsx +++ b/app/[locale]/10years/_components/NFTMintCard/views/MintAlreadyMinted.tsx @@ -3,7 +3,7 @@ import { BaseLink } from "@/components/ui/Link" export default function MintAlreadyMinted() { const tweetText = encodeURIComponent( - "🎉 I have my free 10th-Anniversary collectible NFT from ethereum.org 🔷 Celebrating a decade of open, decentralized innovation. Join me 👉 https://ethereum.org/en/10years/ #Ethereum10" + "🎉 I have my free 10th-Anniversary collectible NFT from ethereum.org 🔷 Celebrating a decade of open, decentralized innovation. Join me 👉 https://ethereum.org/10years/ #Ethereum10" ) const tweetUrl = `https://twitter.com/intent/tweet?text=${tweetText}` diff --git a/app/[locale]/10years/_components/NFTMintCard/views/MintSuccess.tsx b/app/[locale]/10years/_components/NFTMintCard/views/MintSuccess.tsx index dde859367f0..9cb1dbb5115 100644 --- a/app/[locale]/10years/_components/NFTMintCard/views/MintSuccess.tsx +++ b/app/[locale]/10years/_components/NFTMintCard/views/MintSuccess.tsx @@ -13,7 +13,7 @@ import { getTxEtherscanUrl } from "@/lib/torch" export default function MintSuccess({ txHash }: { txHash?: string }) { const tweetText = encodeURIComponent( - "🎉 I just claimed my free 10th-Anniversary collectible NFT from ethereum.org 🔷 Celebrating a decade of open, decentralized innovation. Join me 👉 https://ethereum.org/en/10years/ #Ethereum10" + "🎉 I just claimed my free 10th-Anniversary collectible NFT from ethereum.org 🔷 Celebrating a decade of open, decentralized innovation. Join me 👉 https://ethereum.org/10years/ #Ethereum10" ) const tweetUrl = `https://twitter.com/intent/tweet?text=${tweetText}` diff --git a/docs/header-ids.md b/docs/header-ids.md index f8462ea3ff6..9aaf273fd5a 100644 --- a/docs/header-ids.md +++ b/docs/header-ids.md @@ -30,7 +30,7 @@ When these headers are rendered, they come with a link icon attached to it that Extending the above example, if we wanted to link to the `A subheading` section of the above document (for example living at path `/docs`), you could use the link`/docs#a-subheading` to link directly to that section. -See a live example on ethereum.org: [https://ethereum.org/en/developers/docs/blocks/#block-anatomy](https://ethereum.org/en/developers/docs/blocks/#block-anatomy) +See a live example on ethereum.org: [https://ethereum.org/developers/docs/blocks/#block-anatomy](https://ethereum.org/developers/docs/blocks/#block-anatomy) ## When to use custom header IDs @@ -44,7 +44,7 @@ English files are uploaded to Crowdin for translation. Header ID's should be _in This is to ensure that the translated content can be linked to from other documents and external links, without breaking the path. This is similar to why path and filenames are not translated, but remain in English to simplify linking and referencing. -See a live example on ethereum.org: [https://ethereum.org/es/developers/docs/blocks/#block-anatomy](https://ethereum.org/en/developers/docs/blocks/#block-anatomy) +See a live example on ethereum.org: [https://ethereum.org/es/developers/docs/blocks/#block-anatomy](https://ethereum.org/developers/docs/blocks/#block-anatomy) Notice the header ID is still in English (`#block-anatomy`), but links to the Spanish (`/es/`) version of the site, at the correct section. diff --git a/docs/stack.md b/docs/stack.md index fee94af11e4..6d3b4107490 100644 --- a/docs/stack.md +++ b/docs/stack.md @@ -25,7 +25,7 @@ | `/src` | Main source folder for development. | | `/public/assets` | Image assets. | | `/src/components` | React components that do not function as standalone pages. | -| `/public/content` | Markdown/MDX files for site content stored here.
For example: `ethereum.org/en/about/` is built from `public/content/about/index.md`
The markdown files are parsed by `[...slug].tsx` and rendered using the proper layout in `ContentPage.getLayout` method. | +| `/public/content` | Markdown/MDX files for site content stored here.
For example: `ethereum.org/about/` is built from `public/content/about/index.md`
The markdown files are parsed by `[...slug].tsx` and rendered using the proper layout in `ContentPage.getLayout` method. | | `/public/content/developers/docs` | \*Markdown files in here use the Docs layout: `src/layouts/Docs.tsx` | | `/public/content/developers/tutorials` | \*Markdown files in here use the Tutorial layout: `src/layouts/Tutorial.tsx` | | `/src/data` | General data files importable by components. | diff --git a/docs/translation-program.md b/docs/translation-program.md index 880be48e90c..8e8e47a1143 100644 --- a/docs/translation-program.md +++ b/docs/translation-program.md @@ -4,4 +4,4 @@ _The Translation Program is an initiative to translate ethereum.org into differe If you are looking to get involved as a translator, you can [join our project in Crowdin](https://crowdin.com/project/ethereum-org/) and start translating the website into your language immediately. -To get more information about the program, learn how to use Crowdin, check on the progress or find some useful tools for translators, please visit the [Translation Program page](https://ethereum.org/en/contributing/translation-program/). +To get more information about the program, learn how to use Crowdin, check on the progress or find some useful tools for translators, please visit the [Translation Program page](https://ethereum.org/contributing/translation-program/). diff --git a/public/.well-known/security.txt b/public/.well-known/security.txt index f5633e95685..739dcbea17f 100644 --- a/public/.well-known/security.txt +++ b/public/.well-known/security.txt @@ -8,7 +8,7 @@ Acknowledgments: https://bounty.ethereum.org Preferred-Languages: en Canonical: https://ethereum.org/.well-known/security.txt Policy: https://bounty.ethereum.org -Hiring: https://ethereum.org/en/community/get-involved/#ethereum-jobs +Hiring: https://ethereum.org/community/get-involved/#ethereum-jobs -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEErpbtlp5HmwCE8+F/6I0zNPpfagoFAmXYslMACgkQ6I0zNPpf diff --git a/public/content/community/events/organizing/index.md b/public/content/community/events/organizing/index.md index aaee9ef1055..c27dd1279b3 100644 --- a/public/content/community/events/organizing/index.md +++ b/public/content/community/events/organizing/index.md @@ -16,8 +16,8 @@ A successful Ethereum conference is built on an active and engaged community. If **Your first steps should be:** - Explore local startups and companies — having strong, active companies in your city or country is often the most critical prerequisite for building a community. -- Check if there are already some meetups — ethereum.org [events page](https://ethereum.org/en/community/events/) -- [The ethereum.org website](https://ethereum.org/en/community/events/) and ethereum.org Discord — to check if there are local Ethereum events, developers, and contributors. +- Check if there are already some meetups — ethereum.org [events page](https://ethereum.org/community/events/) +- [The ethereum.org website](https://ethereum.org/community/events/) and ethereum.org Discord — to check if there are local Ethereum events, developers, and contributors. - Luma and Meetup.com — to see if there are Ethereum-related events or broader web3 events happening in your area. - X — Try to find local advocates or influencers in the space. @@ -114,7 +114,7 @@ Once you’ve tapped into local support, expand your outreach to global players #### Alternative forms of funding your event {#alternative-forms-of-funding-your-event} -Grants are another potential funding source that many organizers overlook. Programs like the Ethereum Foundation’s [Ecosystem Support Program](https://esp.ethereum.foundation/) (ESP) and [other grant initiatives](https://ethereum.org/en/community/grants/#ethereum-grants) exist to support community-driven events. +Grants are another potential funding source that many organizers overlook. Programs like the Ethereum Foundation’s [Ecosystem Support Program](https://esp.ethereum.foundation/) (ESP) and [other grant initiatives](https://ethereum.org/community/grants/#ethereum-grants) exist to support community-driven events. Beyond financial sponsorships, consider in-kind partnerships, especially for food and beverages. Brands that align with the local culture or tech community can be great partners for your event. Coffee brands, beverage companies, or even local pizzerias might be willing to provide products in exchange for visibility at the event. These collaborations can help reduce costs while enhancing the attendee experience. diff --git a/public/content/contributing/style-guide/content-standardization/index.md b/public/content/contributing/style-guide/content-standardization/index.md index de3a5c329c6..aed58de1856 100644 --- a/public/content/contributing/style-guide/content-standardization/index.md +++ b/public/content/contributing/style-guide/content-standardization/index.md @@ -184,7 +184,7 @@ Read more about [smart contracts](/docs/developers/smart-contracts/) Read more about [smart contracts](/en/docs/developers/smart-contracts) -Read more about [smart contracts](https://ethereum.org/en/docs/developers/smart-contracts) +Read more about [smart contracts](/docs/developers/smart-contracts) ``` Please also add a trailing slash to all links. This keeps links consistent and avoids redirects, which hurts site performance. diff --git a/public/content/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/developers/docs/consensus-mechanisms/pos/keys/index.md index fd6b8f9a96b..4c23036aa30 100644 --- a/public/content/developers/docs/consensus-mechanisms/pos/keys/index.md +++ b/public/content/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -56,7 +56,7 @@ Separating the validator keys from the Ethereum account keys enables multiple va ![validator key schematic](validator-key-schematic.png) -**Note**: Exiting from staking duties and withdrawing a validator's balance currently requires signing a [voluntary exit message (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) with the validator key. However, [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) is a proposal that will allow a user to trigger a validator's exit and withdrawals its balance by signing exit messages with the withdrawal key in the future. This will reduce trust assumptions by enabling stakers who delegate ETH to [staking-as-a-service providers](https://ethereum.org/en/staking/saas/#what-is-staking-as-a-service) to remain in control of their funds. +**Note**: Exiting from staking duties and withdrawing a validator's balance currently requires signing a [voluntary exit message (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) with the validator key. However, [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) is a proposal that will allow a user to trigger a validator's exit and withdrawals its balance by signing exit messages with the withdrawal key in the future. This will reduce trust assumptions by enabling stakers who delegate ETH to [staking-as-a-service providers](/staking/saas/#what-is-staking-as-a-service) to remain in control of their funds. ## Deriving keys from a seed phrase {#deriving-keys-from-seed} diff --git a/public/content/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index 2f40d17cc14..9f053f63f88 100644 --- a/public/content/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -11,7 +11,7 @@ Ethereum's data structure is a 'modified Merkle-Patricia Trie', named so because A Merkle-Patricia trie is deterministic and cryptographically verifiable: The only way to generate a state root is by computing it from each individual piece of the state, and two states that are identical can be easily proven so by comparing the root hash and the hashes that led to it (_a Merkle proof_). Conversely, there is no way to create two different states with the same root hash, and any attempt to modify state with different values will result in a different state root hash. Theoretically, this structure provides the 'holy grail' of `O(log(n))` efficiency for inserts, lookups and deletes. -In the near future, Ethereum plans to migrate to a [Verkle Tree](https://ethereum.org/en/roadmap/verkle-trees) structure, which will open up many new possibilities for future protocol improvements. +In the near future, Ethereum plans to migrate to a [Verkle Tree](/roadmap/verkle-trees) structure, which will open up many new possibilities for future protocol improvements. ## Prerequisites {#prerequisites} diff --git a/public/content/developers/docs/standards/tokens/erc-223/index.md b/public/content/developers/docs/standards/tokens/erc-223/index.md index a5f61c63e8e..5955f3f84ae 100644 --- a/public/content/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/developers/docs/standards/tokens/erc-223/index.md @@ -178,7 +178,7 @@ contract RecipientContract is IERC223Recipient { } ``` -When the `RecipientContract` will receive a ERC-223 token the contract will execute a function encoded as `_data` parameter of the token transaction, identical to how ether transactions encode function calls as transaction `data`. Read [the data field](https://ethereum.org/en/developers/docs/transactions/#the-data-field) for more information. +When the `RecipientContract` will receive a ERC-223 token the contract will execute a function encoded as `_data` parameter of the token transaction, identical to how ether transactions encode function calls as transaction `data`. Read [the data field](/developers/docs/transactions/#the-data-field) for more information. In the above example an ERC-223 token must be transferred to the address of the `RecipientContract` with the `transfer(address,uin256,bytes calldata _data)` function. If the data parameter will be `0xc2985578` (the signature of a `foo()` function) then the function foo() will be invoked after the token deposit is received and the event Foo() will be fired. diff --git a/public/content/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md b/public/content/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md index 9d36beed9cb..96cd2d20dfe 100644 --- a/public/content/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md +++ b/public/content/developers/tutorials/creating-a-wagmi-ui-for-your-contract/index.md @@ -501,7 +501,7 @@ export { chains } ### Adding another blockchain {#add-blockchain} -These days there are a lot of [L2 scaling solution](https://ethereum.org/en/layer-2/), and you might want to support some that viem does not support yet. To do it, you modify `src/wagmi.ts`. These instructions explain how to add [Redstone Holesky](https://redstone.xyz/docs/network-info). +These days there are a lot of [L2 scaling solution](/layer-2/), and you might want to support some that viem does not support yet. To do it, you modify `src/wagmi.ts`. These instructions explain how to add [Redstone Holesky](https://redstone.xyz/docs/network-info). 1. Import the `defineChain` type from viem. diff --git a/public/content/developers/tutorials/secret-state/index.md b/public/content/developers/tutorials/secret-state/index.md index d9fec00d08f..f9a5ae7c0b4 100644 --- a/public/content/developers/tutorials/secret-state/index.md +++ b/public/content/developers/tutorials/secret-state/index.md @@ -585,7 +585,7 @@ It still fails, but now it fails without a reason because it happens during the ### How can a user verify the zero trust code? {#user-verify-zero-trust} -Smart contracts are relatively easy to verify. Typically, the developer publishes the source code to a block explorer, and the block explorer verifies that the source code does compile to the code in the [contract deployment transaction](https://ethereum.org/en/developers/docs/smart-contracts/deploying/). In the case of MUD `System`s this is [slightly more complicated](https://mud.dev/cli/verify), but not by much. +Smart contracts are relatively easy to verify. Typically, the developer publishes the source code to a block explorer, and the block explorer verifies that the source code does compile to the code in the [contract deployment transaction](/developers/docs/smart-contracts/deploying/). In the case of MUD `System`s this is [slightly more complicated](https://mud.dev/cli/verify), but not by much. This is harder with zero-knowledge. The verifier includes some constants and runs some calculations on them. This doesn't tell you what is being proved. diff --git a/public/content/privacy/index.md b/public/content/privacy/index.md index 9a2b05d304a..aa81fde926f 100644 --- a/public/content/privacy/index.md +++ b/public/content/privacy/index.md @@ -8,7 +8,7 @@ lang: en Privacy is not only essential for personal safety, it's a cornerstone of freedom and a key [guarantor for decentralization](https://vitalik.eth.limo/general/2025/04/14/privacy.html). Privacy gives people the ability to express themselves, transact with others, and organize communities freely. But like all blockchains, Ethereum's public ledger makes privacy challenging. -Ethereum is transparent by design. Every onchain action is visible to anyone who looks. While Ethereum offers pseudonymity by linking your activity to a [public key](https://ethereum.org/en/decentralized-identity/#public-key-cryptography) instead of a real-world identity, patterns of activity could be analyzed to reveal sensitive information and identify users. +Ethereum is transparent by design. Every onchain action is visible to anyone who looks. While Ethereum offers pseudonymity by linking your activity to a [public key](/decentralized-identity/#public-key-cryptography) instead of a real-world identity, patterns of activity could be analyzed to reveal sensitive information and identify users. Building privacy-preserving tools into Ethereum can help people, organizations, and institutions interact securely while limiting unnecessary exposure. This makes the ecosystem safer and more practical for a wider range of use cases. @@ -84,7 +84,7 @@ Some projects exploring privacy for proving include [Client Side Proving](https: **Verifiable Delegation**: Assigning a task—like generating a proof—to another party (e.g. a mobile wallet using a server for heavy cryptography) while still being able to verify it was done correctly -**[Zero-Knowledge Proofs](https://ethereum.org/en/zero-knowledge-proofs/#why-zero-knowledge-proofs-are-important) (ZKPs)**: Cryptographic protocols that let someone prove information is true without revealing the underlying data +**[Zero-Knowledge Proofs](/zero-knowledge-proofs/#why-zero-knowledge-proofs-are-important) (ZKPs)**: Cryptographic protocols that let someone prove information is true without revealing the underlying data **ZK Rollup**: A scalability system that batches transactions off-chain and submit a validity proof onchain—not private by default, but they enable efficient privacy systems (like shielded pools) by reducing costs @@ -94,4 +94,4 @@ Some projects exploring privacy for proving include [Client Side Proving](https: - [Web3PrivacyNow](https://web3privacy.info/), a network of people, projects, and aligned organizations who protect and advance human rights online - [WalletBeat](https://beta.walletbeat.eth.limo/wallet/summary/), an Ethereum wallet rating site aiming to provide a comprehensive list of wallets, their functionality, practices, and support for certain standards. - [Zk-kit](https://zkkit.pse.dev/): A set of libraries (algorithms, utility functions, and data structures) that can be reused in different projects and zero-knowledge protocols. -- [Privacy Apps](https://ethereum.org/en/apps/categories/privacy/) - Discover a list of curated Privacy applications that run on Ethereum. +- [Privacy Apps](/apps/categories/privacy/) - Discover a list of curated Privacy applications that run on Ethereum. diff --git a/public/content/translations/el/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/el/developers/docs/consensus-mechanisms/pos/keys/index.md index b6400b3d73f..bc470be6799 100644 --- a/public/content/translations/el/developers/docs/consensus-mechanisms/pos/keys/index.md +++ b/public/content/translations/el/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -56,7 +56,7 @@ lang: el ![σχήμα κλειδιού επικυρωτή](validator-key-schematic.png) -**Σημείωση**: Η έξοδος από τα καθήκοντα δέσμευσης κεφαλαίου και η απόσυρση του υπολοίπου ενός επικυρωτή προϋποθέτει προς το παρόν την υπογραφή ενός [μηνύματος εθελοντικής εξόδου (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) με το κλειδί επικύρωσης. Ωστόσο, το [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) είναι μια πρόταση που θα επιτρέψει σε έναν χρήστη να ενεργοποιήσει την έξοδο ενός εργαλείου επικύρωσης και να αποσύρει το υπόλοιπό του υπογράφοντας μηνύματα εξόδου με το κλειδί ανάληψης στο μέλλον. Αυτό θα μειώσει τις υποθέσεις εμπιστοσύνης επιτρέποντας στους συμμετέχοντες που εκχωρούν ETH στους [παρόχους δέσμευσης κεφαλαίου ως υπηρεσία](https://ethereum.org/en/staking/saas/#what-is-staking-as-a-service) να διατηρήσουν τον έλεγχο των κεφαλαίων τους. +**Σημείωση**: Η έξοδος από τα καθήκοντα δέσμευσης κεφαλαίου και η απόσυρση του υπολοίπου ενός επικυρωτή προϋποθέτει προς το παρόν την υπογραφή ενός [μηνύματος εθελοντικής εξόδου (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) με το κλειδί επικύρωσης. Ωστόσο, το [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) είναι μια πρόταση που θα επιτρέψει σε έναν χρήστη να ενεργοποιήσει την έξοδο ενός εργαλείου επικύρωσης και να αποσύρει το υπόλοιπό του υπογράφοντας μηνύματα εξόδου με το κλειδί ανάληψης στο μέλλον. Αυτό θα μειώσει τις υποθέσεις εμπιστοσύνης επιτρέποντας στους συμμετέχοντες που εκχωρούν ETH στους [παρόχους δέσμευσης κεφαλαίου ως υπηρεσία](/staking/saas/#what-is-staking-as-a-service) να διατηρήσουν τον έλεγχο των κεφαλαίων τους. ## Παράγωγη Κλειδιών από Μυστική Φράση {#deriving-keys-from-seed} diff --git a/public/content/translations/el/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/el/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index 38da506fb89..b2a845c19c0 100644 --- a/public/content/translations/el/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/el/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -11,7 +11,7 @@ sidebarDepth: 2 A Merkle-Patricia trie is deterministic and cryptographically verifiable: The only way to generate a state root is by computing it from each individual piece of the state, and two states that are identical can be easily proven so by comparing the root hash and the hashes that led to it (_a Merkle proof_). Αντίθετα, δεν υπάρχει τρόπος να δημιουργηθούν δύο διαφορετικές καταστάσεις με το ίδιο hash ρίζας, και οποιαδήποτε προσπάθεια τροποποίησης της κατάστασης με διαφορετικές τιμές θα οδηγήσει σε διαφορετικό hash ρίζας κατάστασης. Θεωρητικά, αυτή η δομή παρέχει το 'ιερό δισκοπότηρο' της απόδοσης `O(log(n))` για εισαγωγές, αναζητήσεις και διαγραφές. -Στο κοντινό μέλλον, το Ethereum σχεδιάζει να μεταφερθεί σε μια δομή [Verkle Tree](https://ethereum.org/en/roadmap/verkle-trees), η οποία θα ανοίξει πολλές νέες δυνατότητες για μελλοντικές βελτιώσεις του πρωτοκόλλου. +Στο κοντινό μέλλον, το Ethereum σχεδιάζει να μεταφερθεί σε μια δομή [Verkle Tree](/roadmap/verkle-trees), η οποία θα ανοίξει πολλές νέες δυνατότητες για μελλοντικές βελτιώσεις του πρωτοκόλλου. ## Προαπαιτούμενα {#prerequisites} diff --git a/public/content/translations/el/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/el/developers/docs/standards/tokens/erc-223/index.md index 84051c7580d..5f74977605d 100644 --- a/public/content/translations/el/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/translations/el/developers/docs/standards/tokens/erc-223/index.md @@ -177,7 +177,7 @@ contract RecipientContract is IERC223Recipient { } ``` -Όταν το `RecipientContract` λάβει ένα ψηφιακό στοιχείο ERC-223, το συμβόλαιο θα εκτελέσει μια συνάρτηση κωδικοποιημένη ως παράμετρος `_data` της συναλλαγής ψηφιακού στοιχείου, πανομοιότυπη με τον τρόπο με τον οποίο οι συναλλαγές ether κωδικοποιούν τις κλήσεις συναρτήσεων ως `δεδομένα` συναλλαγών. Διαβάστε το [πεδίο δεδομένων](https://ethereum.org/en/developers/docs/transactions/#the-data-field) για περισσότερες πληροφορίες. +Όταν το `RecipientContract` λάβει ένα ψηφιακό στοιχείο ERC-223, το συμβόλαιο θα εκτελέσει μια συνάρτηση κωδικοποιημένη ως παράμετρος `_data` της συναλλαγής ψηφιακού στοιχείου, πανομοιότυπη με τον τρόπο με τον οποίο οι συναλλαγές ether κωδικοποιούν τις κλήσεις συναρτήσεων ως `δεδομένα` συναλλαγών. Διαβάστε το [πεδίο δεδομένων](/developers/docs/transactions/#the-data-field) για περισσότερες πληροφορίες. Στο παραπάνω παράδειγμα, ένα ψηφιακό στοιχείο ERC-223 πρέπει να μεταφερθεί στη διεύθυνση του `RecipientContract` με τη συνάρτηση `transfer(address,uin256,bytes calldata _data)`. Εάν η παράμετρος δεδομένων είναι `0xc2985578` (η υπογραφή μιας συνάρτησης `foo()`), τότε η συνάρτηση foo() θα κληθεί μετά τη λήψη της κατάθεσης ψηφιακού στοιχείου και το συμβάν Foo() θα ενεργοποιηθεί. diff --git a/public/content/translations/es/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/es/developers/docs/consensus-mechanisms/pos/keys/index.md index a48751e78a4..bf573e04f89 100644 --- a/public/content/translations/es/developers/docs/consensus-mechanisms/pos/keys/index.md +++ b/public/content/translations/es/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -56,7 +56,7 @@ La separación de las claves del validador de las claves de la cuenta de Ethereu ![esquema de la clave del validador](validator-key-schematic.png) -**Nota**: Salir de las funciones de participación y retirar el balance del validador actualmente requiere firmar un [mensaje de salida voluntaria (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) con la clave de validador. Sin embargo, [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) es una propuesta que permitirá a un usuario activar la salida de un validador y retirar su balance firmando mensajes de salida con la clave de retirada en el futuro. Esto reducirá las suposiciones de confianza al permitir que los participantes que delegan ETH a [proveedores de participación como servicio](https://ethereum.org/en/staking/saas/#what-is-staking-as-a-service) mantengan el control de sus fondos. +**Nota**: Salir de las funciones de participación y retirar el balance del validador actualmente requiere firmar un [mensaje de salida voluntaria (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) con la clave de validador. Sin embargo, [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) es una propuesta que permitirá a un usuario activar la salida de un validador y retirar su balance firmando mensajes de salida con la clave de retirada en el futuro. Esto reducirá las suposiciones de confianza al permitir que los participantes que delegan ETH a [proveedores de participación como servicio](/staking/saas/#what-is-staking-as-a-service) mantengan el control de sus fondos. ## Derivar claves de una frase semilla {#deriving-keys-from-seed} diff --git a/public/content/translations/es/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/es/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index c6c33c141c6..1cfd124f3ea 100644 --- a/public/content/translations/es/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/es/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -11,7 +11,7 @@ La estructura de datos de Ethereum es un «trie Merkle-Patricia modificado», ll Un trie de Merkle-Patricia es determinista y criptográficamente verificable: la única manera de generar una raíz de estado es calculándola a partir de cada pieza individual del estado, y dos estados que son idénticos se pueden probar fácilmente comparando el hash raíz y los hashes que lo llevaron a él (_una prueba de Merkle_). Por el contrario, no hay forma de crear dos estados diferentes con el mismo hash raíz, y cualquier intento de modificar el estado con diferentes valores dará como resultado un hash raíz de estado diferente. En teoría, esta estructura proporciona el «santo grial» de `O(log(n))` eficiencia para inserciones, búsquedas y eliminaciones. -En un futuro próximo, Ethereum planea migrar a una estructura de [árbol Verkle](https://ethereum.org/en/roadmap/verkle-trees), lo que abrirá muchas y nuevas posibilidades para futuras mejoras del protocolo. +En un futuro próximo, Ethereum planea migrar a una estructura de [árbol Verkle](/roadmap/verkle-trees), lo que abrirá muchas y nuevas posibilidades para futuras mejoras del protocolo. ## Requisitos previos {#prerequisites} diff --git a/public/content/translations/es/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/es/developers/docs/standards/tokens/erc-223/index.md index 4cfa09fc1e9..631473def1f 100644 --- a/public/content/translations/es/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/translations/es/developers/docs/standards/tokens/erc-223/index.md @@ -177,7 +177,7 @@ contract RecipientContract is IERC223Recipient { } ``` -Cuando el `RecipientContract` recibe un token ERC-223, el contrato ejecutará una función codificada con el parámetro `_data` que corresponde a la transacción del token. Esto es idéntico al modo en que las transacciones de Ether codifican las llamadas a funciones como `data` de transacción. Lea [el campo de datos](https://ethereum.org/en/developers/docs/transactions/#the-data-field) para obtener más información. +Cuando el `RecipientContract` recibe un token ERC-223, el contrato ejecutará una función codificada con el parámetro `_data` que corresponde a la transacción del token. Esto es idéntico al modo en que las transacciones de Ether codifican las llamadas a funciones como `data` de transacción. Lea [el campo de datos](/developers/docs/transactions/#the-data-field) para obtener más información. En el ejemplo anterior, se debe transferir un token ERC-223 a la dirección del `RecipientContract` con la función `transfer(address,uin256,bytes calldata _data)`. Si el parámetro de los datos será `0xc2985578` (la firma de una función `foo()`), la función foo() será invocada luego de que se reciba el depósito y se disparará el evento Foo(). diff --git a/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index 42a5716204f..b4c62fd0fb3 100644 --- a/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/fa/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -11,7 +11,7 @@ sidebarDepth: 2 درخت مرکل-پاتریشیا متغیر قطعی و از نظر رمزنگاری قابل تأیید است: تنها راه برای تولید ریشه حالت، محاسبه آن از تک تک تکه های حالت است، و دو حالت یکسان را می توان به راحتی با مقایسه هش ریشه و هش هایی که منجر به آن شده‌اند ثابت کرد (_اثبات مرکل_). برعکس، هیچ راهی برای ایجاد دو حالت مختلف با هش ریشه یکسان وجود ندارد، و هر تلاشی برای تغییر حالت با مقادیر مختلف منجر به یک هش ریشه متفاوت خواهد شد. از نظر تئوری، این ساختار «جام مقدس» کارایی `O(log(n))` را برای درج‌ها، جستجوها و حذف‌ها فراهم می‌کند. -در آینده نزدیک، اتریوم قصد دارد به ساختار [Verkle Tree](https://ethereum.org/en/roadmap/verkle-trees) مهاجرت کند، که بسیاری از فرصت‌های جدید را برای بهبود پروتکل‌های آینده باز خواهد کرد. +در آینده نزدیک، اتریوم قصد دارد به ساختار [Verkle Tree](/roadmap/verkle-trees) مهاجرت کند، که بسیاری از فرصت‌های جدید را برای بهبود پروتکل‌های آینده باز خواهد کرد. ## موارد مورد نیاز {#prerequisites} diff --git a/public/content/translations/fa/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/fa/developers/docs/standards/tokens/erc-223/index.md index ff0172e93a7..1fa19255ce4 100644 --- a/public/content/translations/fa/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/translations/fa/developers/docs/standards/tokens/erc-223/index.md @@ -186,7 +186,7 @@ contract RecipientContract is IERC223Recipient { } ``` -هنگامی که `RecipientContract` یک توکن ERC-223 را دریافت می‌کند، درست همانطور که تراکنش‌های ارسال اتر فراخوانی توابع را بعنوان `data` در تراکنش کدنگاری می‌کنند، قرارداد نیز تابعی را که به عنوان متغیر `_data` در تراکنش توکن کدنگاری شده است اجرا خواهد کرد. برای اطلاعات بیشتر [دیتا فیلد](https://ethereum.org/en/developers/docs/transactions/#the-data-field) را مطالعه فرمائید. +هنگامی که `RecipientContract` یک توکن ERC-223 را دریافت می‌کند، درست همانطور که تراکنش‌های ارسال اتر فراخوانی توابع را بعنوان `data` در تراکنش کدنگاری می‌کنند، قرارداد نیز تابعی را که به عنوان متغیر `_data` در تراکنش توکن کدنگاری شده است اجرا خواهد کرد. برای اطلاعات بیشتر [دیتا فیلد](/developers/docs/transactions/#the-data-field) را مطالعه فرمائید. در مثال بالا، توکن ERC-223 باید با استفاده از تابع `transfer(address,uin256,bytes calldata _data)` به آدرس `RecipientContract` انتقال یابد. اگر مقدار پارامتر دیتا `0xc2985578` باشد (معادل امضاء تابع `foo()`)، بعد از دریافت توکن واریزی و اجراء رویداد Foo()، تابع foo() اجرا خواهد شد. diff --git a/public/content/translations/fr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/fr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index 4628119a47c..fe93186638a 100644 --- a/public/content/translations/fr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/fr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -11,7 +11,7 @@ La structure de données d'Ethereum est un arbre de Patricia Merkle modifié, no Un arbre de Patricia Merkle est déterministe et cryptographiquement vérifiable : la seule façon de générer une racine d'état est de la calculer à partir de chaque morceau individuel de l'état, et deux états qui sont identiques peuvent être facilement prouvés en comparant le hash de racine et les hashes qui y ont conduit (_a Merkle proof_). Inversement, il n'est pas possible de créer deux états différents avec le même hachage de racine, et toute tentative de modifier l'état avec différentes valeurs donnera lieu à un hachage de racine d'état différent. Théoriquement, cette structure fournit le sacré Graal de l'efficacité `O(log(n))` pour les inserts, les recherches et les suppressions. -Dans un avenir proche, Ethereum prévoit de migrer vers une structure en [arbre de Verkle](https://ethereum.org/en/roadmap/verkle-trees), ce qui ouvrira de nombreuses possibilités d'amélioration du protocole. +Dans un avenir proche, Ethereum prévoit de migrer vers une structure en [arbre de Verkle](/roadmap/verkle-trees), ce qui ouvrira de nombreuses possibilités d'amélioration du protocole. ## Prérequis {#prerequisites} diff --git a/public/content/translations/fr/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/fr/developers/docs/standards/tokens/erc-223/index.md index 460ea011df7..a44a4377320 100644 --- a/public/content/translations/fr/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/translations/fr/developers/docs/standards/tokens/erc-223/index.md @@ -178,7 +178,7 @@ contract RecipientContract is IERC223Recipient { } ``` -Lorsque le 'RecipientContract' recevra un token ERC-223, le contrat exécutera une fonction encodée sous forme de paramètre '_data' de la transaction du jeton, de la même manière que les transactions d'ether encodent les appels de fonction en tant que 'data' de transaction. Consultez [le champ de données](https://ethereum.org/en/developers/docs/transactions/#the-data-field) pour plus d'informations. +Lorsque le 'RecipientContract' recevra un token ERC-223, le contrat exécutera une fonction encodée sous forme de paramètre '_data' de la transaction du jeton, de la même manière que les transactions d'ether encodent les appels de fonction en tant que 'data' de transaction. Consultez [le champ de données](/developers/docs/transactions/#the-data-field) pour plus d'informations. Dans l'exemple ci-dessus, un jeton ERC-223 doit être transféré à l'adresse du `RecipientContract` avec la fonction `transfer(address,uint256,bytes calldata _data)`. Si le paramètre de données est `0xc2985578` (la signature de la fonction `faut()`), alors la fonction `foo()` sera invoquée après la réception du dépôt de jetons, et l'événement `Foo()` sera déclenché. diff --git a/public/content/translations/ga/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/ga/developers/docs/standards/tokens/erc-223/index.md index e2109aa5174..901971f8787 100644 --- a/public/content/translations/ga/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/translations/ga/developers/docs/standards/tokens/erc-223/index.md @@ -177,7 +177,7 @@ contract RecipientContract is IERC223Recipient { } ``` -Nuair a gheobhaidh an `RecipientContract` chomhartha ERC-223 déanfaidh an conradh feidhm atá ionchódaithe mar pharaiméadar `_data` an idirbhirt chomharthaí, comhionann leis an gcaoi a n-ionchódaíonn idirbhearta éitear glaonna mar `data` idirbhirt. Léigh [an réimse sonraí] (https://ethereum.org/en/developers/docs/transactions/#the-data-field) le haghaidh tuilleadh faisnéise. +Nuair a gheobhaidh an `RecipientContract` chomhartha ERC-223 déanfaidh an conradh feidhm atá ionchódaithe mar pharaiméadar `_data` an idirbhirt chomharthaí, comhionann leis an gcaoi a n-ionchódaíonn idirbhearta éitear glaonna mar `data` idirbhirt. Léigh [an réimse sonraí] (/developers/docs/transactions/#the-data-field) le haghaidh tuilleadh faisnéise. Sa sampla thuas ní mór comhartha ERC-223 a aistriú chuig seoladh an `RecipientContract` leis an bhfeidhm `transfer(address,uin256,bytes calldata _data)`. Más é `0xc2985578` (síniú feidhm `foo()`) an paraiméadar sonraí, déanfar an foo feidhme () a agairt tar éis an taisce chomhartha a fháil agus déanfar an t-imeacht Foo() a bhácáil. diff --git a/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/keys/index.md index f91afa32a91..70e2a185b2c 100644 --- a/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/keys/index.md +++ b/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -56,7 +56,7 @@ A validátorkulcsok és az Ethereum-számlakulcsok szétválasztása lehetővé ![validátorkulcs ábrája](validator-key-schematic.png) -**Megjegyzés**: A letétbe helyezésből való kilépéshez és a validátor egyenlegének visszavonásához jelenleg egy [önkéntes kilépési üzenet (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) aláírása szükséges a validátorkulccsal. Az [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) azonban egy olyan javaslat, amely lehetővé teszi a felhasználó számára, hogy a jövőben a kilépési üzeneteknek a kivételi kulccsal történő aláírásával elindítsa a validátor kilépését és kivegye az egyenlegét. Ez csökkenti a bizalomigényt, mivel azok a letétesek, akik az ETH-t [letétbe helyezési szolgáltatóknak](https://ethereum.org/en/staking/saas/#what-is-staking-as-a-service) delegálják, továbbra is ellenőrzésük alatt tarthatják pénzeszközeiket. +**Megjegyzés**: A letétbe helyezésből való kilépéshez és a validátor egyenlegének visszavonásához jelenleg egy [önkéntes kilépési üzenet (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) aláírása szükséges a validátorkulccsal. Az [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) azonban egy olyan javaslat, amely lehetővé teszi a felhasználó számára, hogy a jövőben a kilépési üzeneteknek a kivételi kulccsal történő aláírásával elindítsa a validátor kilépését és kivegye az egyenlegét. Ez csökkenti a bizalomigényt, mivel azok a letétesek, akik az ETH-t [letétbe helyezési szolgáltatóknak](/staking/saas/#what-is-staking-as-a-service) delegálják, továbbra is ellenőrzésük alatt tarthatják pénzeszközeiket. ## Kulcsok származtatása egy kulcsmondatból {#deriving-keys-from-seed} diff --git a/public/content/translations/hu/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/hu/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index 36fbac640a3..4917125f51b 100644 --- a/public/content/translations/hu/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/hu/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -11,7 +11,7 @@ Az Ethereum adatszerkezete egy „módosított Merkle-Patricia-fa (trie)”, ame A Merkle-Patricia-fa determinisztikus és kriptográfiailag ellenőrizhető: a státusz gyökerét csak úgy lehet előállítani, ha azt a státusz minden egyes darabjából kiszámítjuk, és két azonos státusz könnyen bizonyítható a gyökér-hash és az ahhoz vezető hash-ek az összehasonlításával (_Merkle-bizonyíték_). Ezzel szemben nem lehet két különböző státuszt létrehozni ugyanazzal a gyökér-hash-értékkel, és minden olyan kísérlet, hogy a státuszt különböző értékekkel módosítsák, más státusz gyökér-hash-t eredményez. Elméletileg ez a struktúra biztosítja a `O(log(n))` hatékonyság „szent grálját” a beleírások, keresések és törlések esetében. -A közeljövőben az Ethereum tervezi, hogy áttér a [Verkle-fastruktúrára](https://ethereum.org/en/roadmap/verkle-trees), amely új lehetőségeket nyit a jövőbeli protokollfejlesztések előtt. +A közeljövőben az Ethereum tervezi, hogy áttér a [Verkle-fastruktúrára](/roadmap/verkle-trees), amely új lehetőségeket nyit a jövőbeli protokollfejlesztések előtt. ## Előfeltételek {#prerequisites} diff --git a/public/content/translations/hu/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/hu/developers/docs/standards/tokens/erc-223/index.md index 18750200db6..7b9e55ebae8 100644 --- a/public/content/translations/hu/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/translations/hu/developers/docs/standards/tokens/erc-223/index.md @@ -177,7 +177,7 @@ contract RecipientContract is IERC223Recipient { } ``` -Amikor a „RecipientContract” kap egy ERC-223 tokent, a szerződés a token tranzakció „_data” paramétereként kódolt függvényt hajt végre ugyanúgy, ahogy az ether-tranzakciók kódolják a függvényhívásokat a tranzakció „data” paramétereként. Tekintse meg [az adatmezőt](https://ethereum.org/en/developers/docs/transactions/#the-data-field) további információért. +Amikor a „RecipientContract” kap egy ERC-223 tokent, a szerződés a token tranzakció „_data” paramétereként kódolt függvényt hajt végre ugyanúgy, ahogy az ether-tranzakciók kódolják a függvényhívásokat a tranzakció „data” paramétereként. Tekintse meg [az adatmezőt](/developers/docs/transactions/#the-data-field) további információért. A fenti példában az ERC-223 tokent a „RecipientContract” címre a „transfer(address,uin256,bytes calldata _data)” függvénnyel kell küldeni. Ha az adatparaméter „0xc2985578” (ami a „foo()” függvény jele), akkor a foo() függvény indul el a token letétbe helyezése után, és a Foo() eseményt adja. diff --git a/public/content/translations/it/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/it/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index 47aac178592..1c7ad65d411 100644 --- a/public/content/translations/it/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/it/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -11,7 +11,7 @@ La struttura dei dati di Ethereum è un 'Trie di Merkle-Patricia modificato', co Un trie di Merkle-Patricia è deterministico e verificabile crittograficamente: il solo modo per generare una radice di stato è calcolandola da ogni singola parte dello stato, e due stati identici sono facilmente dimostrabili confrontando l'hash di radice e gli hash che hanno portato a esso (_una prova di Merkle_). Per contro, non esiste alcun modo per creare due stati differenti con lo stesso hash di radice, e qualsiasi tentativo di modificare lo stato con valori differenti risulterà in un hash della radice di stato differente. Teoricamente, questa struttura rappresenta il 'Sacro Graal' dell'efficienza di `O(log(n))` per inserimenti, ricerche ed eliminazioni. -Nel prossimo futuro, Ethereum prevede di migrare a una struttura ad [Albero di Verkle](https://ethereum.org/en/roadmap/verkle-trees), che aprirà le porte a molte nuove possibilità per le future migliorie al protocollo. +Nel prossimo futuro, Ethereum prevede di migrare a una struttura ad [Albero di Verkle](/roadmap/verkle-trees), che aprirà le porte a molte nuove possibilità per le future migliorie al protocollo. ## Prerequisiti {#prerequisites} diff --git a/public/content/translations/it/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/it/developers/docs/standards/tokens/erc-223/index.md index fe9ce8e6cf0..a18b66de118 100644 --- a/public/content/translations/it/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/translations/it/developers/docs/standards/tokens/erc-223/index.md @@ -178,7 +178,7 @@ contract RecipientContract is IERC223Recipient { } ``` -Quando il `RecipientContract` riceverà un token ERC-223 il contratto eseguirà una funzione codificata come parametro `_data` della transazione del token, in modo identico a come le transazioni di Ether codificano le chiamate di funzioni come transazioni `data`. Leggi [il campo dati](https://ethereum.org/en/developers/docs/transactions/#the-data-field) per maggiori informazioni. +Quando il `RecipientContract` riceverà un token ERC-223 il contratto eseguirà una funzione codificata come parametro `_data` della transazione del token, in modo identico a come le transazioni di Ether codificano le chiamate di funzioni come transazioni `data`. Leggi [il campo dati](/developers/docs/transactions/#the-data-field) per maggiori informazioni. Nell'esempio precedente un token ERC-223 deve essere trasferito all'indirizzo del `RecipientContract` con la funzione `transfer(address,uin256,bytes calldata _data)`. Se il parametro dei dati sarà `0xc2985578` (la firma di una funzione `foo()`) allora la funzione foo() sarà invocata dopo che il deposito del token è stato ricevuto e l'evento Foo() è stato attivato. diff --git a/public/content/translations/ja/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/ja/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index 4b695d490b8..cda2c97883b 100644 --- a/public/content/translations/ja/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/ja/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -11,7 +11,7 @@ sidebarDepth: 2 マークル・パトリシア・ツリーは、決定論的で暗号的に検証可能です。状態ルートを生成する唯一の方法は、状態のそれぞれの部分で計算することです。2つの状態が同一であることは、ルートハッシュとその計算から導かれたハッシュを比較することで簡単に証明できます (_マークルプルーフ_) 。 反対に、同じルートハッシュで2つの異なる状態を生成することはあり得ません。また、異なる値で状態を変更しようとすると、異なる状態のルートハッシュになります。 理論的には、この構造により、挿入、検索、削除で`O(log(n))`による効率の「ホーリー・グレイル」を提供します。 -今後、イーサリアムでは[バークルツリー](https://ethereum.org/en/roadmap/verkle-trees)構造への移行を計画しています。これにより、将来のプロトコルの改善において、さまざまな新しい可能性が開かれます。 +今後、イーサリアムでは[バークルツリー](/roadmap/verkle-trees)構造への移行を計画しています。これにより、将来のプロトコルの改善において、さまざまな新しい可能性が開かれます。 ## 前提知識 {#prerequisites} diff --git a/public/content/translations/ja/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/ja/developers/docs/standards/tokens/erc-223/index.md index 2b666764336..499ea17ea2e 100644 --- a/public/content/translations/ja/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/translations/ja/developers/docs/standards/tokens/erc-223/index.md @@ -177,7 +177,7 @@ contract RecipientContract is IERC223Recipient { } ``` -`RecipientContract` がERC-223トークンを受け取ると、そのコントラクトはトークントランザクションの `_data` パラメータにエンコードされた関数を実行します。これはイーサのトランザクションが関数呼び出しをトランザクションの `data` としてエンコードするのと同じです。 詳細については [dataフィールド](https://ethereum.org/en/developers/docs/transactions/#the-data-field) を参照してください。 +`RecipientContract` がERC-223トークンを受け取ると、そのコントラクトはトークントランザクションの `_data` パラメータにエンコードされた関数を実行します。これはイーサのトランザクションが関数呼び出しをトランザクションの `data` としてエンコードするのと同じです。 詳細については [dataフィールド](/developers/docs/transactions/#the-data-field) を参照してください。 上記の例では、ERC-223トークンは `transfer(address,uin256,bytes calldata _data)` 関数を使用して `RecipientContract` のアドレスに転送される必要があります。 dataパラメータが `0xc2985578` （ `foo()` 関数のシグネチャ）である場合、トークンデポジットが完了した後にfoo()関数が呼び出され、Foo()イベントが発行されます。 diff --git a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/keys/index.md index 488f647241a..aa9c8249c3b 100644 --- a/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/keys/index.md +++ b/public/content/translations/pt-br/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -56,7 +56,7 @@ Separar as chaves de validação das chaves da conta Ethereum permite que vário ![esquema da chave de validação](validator-key-schematic.png) -**Nota**: Sair das funções de staking e sacar o saldo de um validador atualmente requer a assinatura de uma [mensagem de saída voluntária (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) com a chave do validador. No entanto, o [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) é uma proposta que permitirá que um usuário acione a saída de um validador e saque seu saldo assinando mensagens de saída com a chave de saque no futuro. Isso reduzirá as suposições de confiança ao permitir que os participantes que delegam ETH a [provedores de staking como serviço](https://ethereum.org/en/staking/saas/#what-is-staking-as-a-service) mantenham o controle de seus fundos. +**Nota**: Sair das funções de staking e sacar o saldo de um validador atualmente requer a assinatura de uma [mensagem de saída voluntária (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) com a chave do validador. No entanto, o [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) é uma proposta que permitirá que um usuário acione a saída de um validador e saque seu saldo assinando mensagens de saída com a chave de saque no futuro. Isso reduzirá as suposições de confiança ao permitir que os participantes que delegam ETH a [provedores de staking como serviço](/staking/saas/#what-is-staking-as-a-service) mantenham o controle de seus fundos. ## Obtendo chaves de uma frase semente {#deriving-keys-from-seed} diff --git a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index 519db935633..bfc38a3162f 100644 --- a/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/pt-br/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -11,7 +11,7 @@ A estrutura de dados do Ethereum é uma 'Merkle-Patricia Trie modificada', assim Uma Merkle-Patricia é determinística e criptograficamente verificável: a única maneira de gerar uma raiz de estado é computando-a a partir de cada parte individual do estado, e dois estados que são idênticos podem ser facilmente provados comparando o hash raiz e os hashes que levaram a ele (_uma prova de Merkle_). Por outro lado, não há como criar dois estados diferentes com o mesmo hash raiz, e qualquer tentativa de modificar o estado com valores diferentes resultará em um hash raiz de estado diferente. Teoricamente, essa estrutura fornece o "Santo Graal" da eficiência `O(log(n))` para inserções, pesquisas e exclusões. -Em um futuro próximo, o Ethereum planeja migrar para uma estrutura de [Verkle Tree](https://ethereum.org/en/roadmap/verkle-trees), o que abrirá muitas novas possibilidades para futuras melhorias de protocolo. +Em um futuro próximo, o Ethereum planeja migrar para uma estrutura de [Verkle Tree](/roadmap/verkle-trees), o que abrirá muitas novas possibilidades para futuras melhorias de protocolo. ## Pré-requisitos {#prerequisites} diff --git a/public/content/translations/tr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/tr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index 3a157782b42..89e6386b129 100644 --- a/public/content/translations/tr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/tr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -11,7 +11,7 @@ Ethereum'un veri yapısı PATRICIA'nın (Alfasayısal Kodlanmış Bilgileri Alma Merkle-Patricia trie, kesin ve kriptografik olarak doğrulanabilirdir: Bir durum kökü üretmenin tek yolu, onu durumun her bir parçasından hesaplamaktır ve aynı olan iki durum, kök karması ve ona yol açan karmalar karşılaştırılarak kolayca kanıtlanabilir (_bir Merkle ispatı_). Tam tersinden bakacak olursak, aynı kök karmasına sahip iki farklı durum oluşturmak mümkün değildir ve farklı değerlere sahip durumları değiştirme girişimi farklı bir durum kök karmasına yol açar. Teorik olarak bu yapı, eklemeler, aramalar ve silmeler için `O(log(n))` verimliliğinin "kutsal kasesini" sağlar. -Ethereum, yakın gelecekte olası protokol geliştirmeleri açısından birçok fırsat yaratacak olan [Verkle Ağacı](https://ethereum.org/en/roadmap/verkle-trees) yapısına geçmeyi düşünüyor. +Ethereum, yakın gelecekte olası protokol geliştirmeleri açısından birçok fırsat yaratacak olan [Verkle Ağacı](/roadmap/verkle-trees) yapısına geçmeyi düşünüyor. ## Ön koşullar {#prerequisites} diff --git a/public/content/translations/tr/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/tr/developers/docs/standards/tokens/erc-223/index.md index dfd24a232f2..e8c87d7c282 100644 --- a/public/content/translations/tr/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/translations/tr/developers/docs/standards/tokens/erc-223/index.md @@ -177,7 +177,7 @@ contract RecipientContract is IERC223Recipient { } ``` -`RecipientContract` bir ERC-223 jetonu aldığında sözleşme, tıpkı Ether işlemlerinin fonksiyon çağrılarını işlem `data` olarak kodlaması gibi jeton işleminin `_data` parametresi olarak kodlanan bir fonksiyonu yürütür. Daha fazla bilgi için [veri alanını](https://ethereum.org/en/developers/docs/transactions/#the-data-field) okuyun. +`RecipientContract` bir ERC-223 jetonu aldığında sözleşme, tıpkı Ether işlemlerinin fonksiyon çağrılarını işlem `data` olarak kodlaması gibi jeton işleminin `_data` parametresi olarak kodlanan bir fonksiyonu yürütür. Daha fazla bilgi için [veri alanını](/developers/docs/transactions/#the-data-field) okuyun. Yukarıdaki örnekte, bir ERC-223 jetonunun `transfer(address,uin256,bytes calldata _data)` fonksiyonu ile `RecipientContract` adresine transferi gerekmektedir. Eğer veri parametresi `0xc2985578` (`foo()` fonksiyonunun imzası) ise, jeton depozitosu alındıktan sonra foo() fonksiyonu çağrılır ve Foo() olayı tetiklenir. diff --git a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index a1d46f18502..315c0fbb414 100644 --- a/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/zh-tw/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -11,7 +11,7 @@ sidebarDepth: 2 默克爾帕特里夏樹是確定性的，並且可以透過加密方式驗證：生成狀態根的唯一方式是從每個單獨的狀態進行計算，且兩個相同的狀態可以透過比較根雜湊和其父雜湊（_默克爾證明_）來簡單地證明相同。 相反，無法用同一個根雜湊建立兩個不同的狀態，任何用不同值修改狀態的嘗試都會導致不同的狀態根雜湊。 從理論上講，這種結構為置入、查找和刪除提供了完美的 `O(log(n))` 效率。 -在不久的將來，以太坊計劃遷移到[沃克爾樹](https://ethereum.org/en/roadmap/verkle-trees)結構，這將為未來的協定改進帶來更多新的可能性。 +在不久的將來，以太坊計劃遷移到[沃克爾樹](/roadmap/verkle-trees)結構，這將為未來的協定改進帶來更多新的可能性。 ## 前置要求 {#prerequisites} diff --git a/public/content/translations/zh/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/zh/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md index 8fb373ff9e2..fc7e8507169 100644 --- a/public/content/translations/zh/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ b/public/content/translations/zh/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -11,7 +11,7 @@ sidebarDepth: 2 默克尔帕特里夏字典树是确定性的并可通过密码学验证：生成状态根的唯一方式是从每个单独的状态进行计算，且两个相同的状态可以通过比较根哈希和父节点哈希（_默克尔证明_）而轻松证明相同。 相反，也无法用同一根哈希创建两个不同的状态，任何用不同值修改状态的尝试都会产生不同的状态根哈希。 理论上，这种结构在插入、查找和删除操作上的效率达到了超乎寻常的 `O(log(n))`。 -在不久的将来，以太坊计划迁移到[沃克尔树](https://ethereum.org/en/roadmap/verkle-trees)结构，这将为未来的协议改进开创更多新的可能性。 +在不久的将来，以太坊计划迁移到[沃克尔树](/roadmap/verkle-trees)结构，这将为未来的协议改进开创更多新的可能性。 ## 前提条件 {#prerequisites} diff --git a/public/content/translations/zh/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/zh/developers/docs/standards/tokens/erc-223/index.md index 15dc96f9d52..aecb499aa5d 100644 --- a/public/content/translations/zh/developers/docs/standards/tokens/erc-223/index.md +++ b/public/content/translations/zh/developers/docs/standards/tokens/erc-223/index.md @@ -177,7 +177,7 @@ contract RecipientContract is IERC223Recipient { } ``` -当 `RecipientContract` 收到 ERC-223 代币时，合约会执行一个编码为代币交易参数 `_data` 的函数，这与以太币交易将函数调用编码为交易 `data` 相同。 阅读[数据字段](https://ethereum.org/en/developers/docs/transactions/#the-data-field)以获取更多信息。 +当 `RecipientContract` 收到 ERC-223 代币时，合约会执行一个编码为代币交易参数 `_data` 的函数，这与以太币交易将函数调用编码为交易 `data` 相同。 阅读[数据字段](/developers/docs/transactions/#the-data-field)以获取更多信息。 在上述示例中，ERC-223 代币必须通过 `transfer(address,uin256,bytes calldata _data)` 函数转移到 `RecipientContract` 的地址。 如果数据参数将为 `0xc2985578`（`foo()` 函数的签名），那么在收到代币存款之后，将会调用 foo() 函数并触发事件 Foo()。