From d22b32be8eedd971701a83eb6fc87668c7e93c93 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:09:29 -0500 Subject: [PATCH 001/212] Adding hard stop guidance to content-standardization --- .../style-guide/content-standardization/index.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/public/content/contributing/style-guide/content-standardization/index.md b/public/content/contributing/style-guide/content-standardization/index.md index de3a5c329c6..c01e9531cd2 100644 --- a/public/content/contributing/style-guide/content-standardization/index.md +++ b/public/content/contributing/style-guide/content-standardization/index.md @@ -172,6 +172,13 @@ Use the "D-Mon-YYYY" format for dates. This format eliminates ambiguity between By adhering to these guidelines, we create a unified approach to presenting dates, fostering clarity and comprehension throughout Ethereum documentation. +### Hard stops (i.e., e.g.,) +When using abbreviations such as i.e., or e.g., it should include the comma after the period. This usage will allow for consistency and presentation. + +**Examples:** +- Preferred: i.e., the preferred usage +- Avoid: i.e. do not use + ### Linking to internal pages {#internal-links} When linking to another page on Ethereum.org, use the relative path over the absolute path. Do not hard-code the language path (i.e. `/en/`) in any links. This maintains consistent functionality across different language versions of the site. From 0c1af168c663472dca4bf9170e8c063d99869e60 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:10:59 -0500 Subject: [PATCH 002/212] hardstops on applying-storyboook --- docs/applying-storybook.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/applying-storybook.md b/docs/applying-storybook.md index 49b3ea8c348..243c5876a9e 100644 --- a/docs/applying-storybook.md +++ b/docs/applying-storybook.md @@ -52,11 +52,11 @@ type Story = StoryObj; export const Basic: Story = {} ``` -- With the `title` option, we write this based on the groupings set by the Design System. Groupings are declared with forward slashes. (i.e. `Atoms / Form / Input`). See the Storybook docs for details on [Naming conventions](https://storybook.js.org/docs/7.0/react/writing-stories/naming-components-and-hierarchy) +- With the `title` option, we write this based on the groupings set by the Design System. Groupings are declared with forward slashes. (i.e., `Atoms / Form / Input`). See the Storybook docs for details on [Naming conventions](https://storybook.js.org/docs/7.0/react/writing-stories/naming-components-and-hierarchy) - The `satisfies` TypeScript keyword is used with the `Meta` type for stricter type checking. This is particularly helpful to make sure required args are not missed. [Storybook Docs regarding `satisfies`](https://storybook.js.org/docs/writing-stories/typescript#using-satisfies-for-better-type-safety) - The use of `StoryObj` is to be able to typecheck the creation of a story as an object. This helps with prop inference. - We use `StoryObj` in the event a required arg is provided in the `meta` object, to be applied to all stories in the file. This prevents type errors throwing at the story level for a required missing arg. -- If the story does not need any args or any custom rendering, it should be left as an empty object. Otherwise, use the `render` option to explicitly write the rendering of the story: i.e. `render: () => ` +- If the story does not need any args or any custom rendering, it should be left as an empty object. Otherwise, use the `render` option to explicitly write the rendering of the story: i.e., `render: () => ` Also, please view the Figma file for the [proposed structure for the Design System](https://www.figma.com/file/Ne3iAassyfAcJ0AlgqioAP/DS-to-storybook-structure?type=design&node-id=42%3A50&mode=design&t=RGkyouvTilzF42y0-1) to provide the correct groupings. From 5bf22071d537b409554bc7719f5485f4eac8d3e8 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:11:28 -0500 Subject: [PATCH 003/212] hardstops code-conventions --- docs/code-conventions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/code-conventions.md b/docs/code-conventions.md index 7f7e87c971c..500f4302e56 100644 --- a/docs/code-conventions.md +++ b/docs/code-conventions.md @@ -63,7 +63,7 @@ For the props type signature use the naming convention `Props` to A positive side-effect to directly annotating the props object is for IDE intellisense where you can view the props when hovering over the component name to see it's signature. -i.e. `const Component: ({ label, title, ...props }: ComponentProps) => React.JSX.Element` +i.e., `const Component: ({ label, title, ...props }: ComponentProps) => React.JSX.Element` #### Use the type alias for props type From 533ef15921396df5e486ea2491f8198f627aa737 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:12:13 -0500 Subject: [PATCH 004/212] hardstops on site-search --- docs/site-search.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/site-search.md b/docs/site-search.md index 14d2a59bb9b..aad13b61985 100644 --- a/docs/site-search.md +++ b/docs/site-search.md @@ -20,7 +20,7 @@ Some important notes about the DocSearch config: - Selectors are used to specify what the crawler should look for when weighting content for the index. - CheerioAPI can be utilized within the crawler using the `$` selector to manipulate the DOM before indexing each page - Elements to be ignored are removed before indexing using the CheerioAPI library: `$('selector').remove()`. This includes `aside`, `nav`, `footer` and `style` elements. -- While building pages, semantic naming with the aforementioned elements, i.e. `aside`, will ignore any content contained within. This is beneficial for content that is not directly related to the page content, such as callouts, banners, quiz content, or navigation elements. +- While building pages, semantic naming with the aforementioned elements, i.e., `aside`, will ignore any content contained within. This is beneficial for content that is not directly related to the page content, such as callouts, banners, quiz content, or navigation elements. ## Resources From 504eaec9b12f765078a9fe6525248064703ec884 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:13:31 -0500 Subject: [PATCH 005/212] hardstops on adding-staking-products/index --- .../contributing/adding-staking-products/index.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/public/content/contributing/adding-staking-products/index.md b/public/content/contributing/adding-staking-products/index.md index 3444c30ed2d..858c7394b62 100644 --- a/public/content/contributing/adding-staking-products/index.md +++ b/public/content/contributing/adding-staking-products/index.md @@ -57,7 +57,7 @@ Staking products or services submissions will be assessed by the following crite **What platforms are supported?** -- i.e. Linux, macOS, Windows, iOS, Android +- i.e., Linux, macOS, Windows, iOS, Android #### Software and smart contracts {#software-and-smart-contracts} @@ -87,18 +87,18 @@ For any custom software or smart contracts involved: For software products related to node or client setup, management or migration: -**Which consensus layer clients (i.e. Lighthouse, Teku, Nimbus, Prysm, Grandine) are supported?** +**Which consensus layer clients (i.e., Lighthouse, Teku, Nimbus, Prysm, Grandine) are supported?** - Which clients are supported? Can the user choose? - This is used to determine the products "multi-client" score. #### Staking as a service {#staking-as-a-service} -For [staking-as-a-service listings](/staking/saas/) (i.e. delegated node operation): +For [staking-as-a-service listings](/staking/saas/) (i.e., delegated node operation): **What are the fees associated with using the service?** -- What is the fee structure, e.g. is there a monthly fee for the service? +- What is the fee structure, e.g., is there a monthly fee for the service? - Any additional staking requirements? **Are users required to sign-up for an account?** @@ -123,7 +123,7 @@ For [pooled staking services](/staking/pools/): **What is the minimum ETH required to stake?** -- e.g. 0.01 ETH +- e.g., 0.01 ETH **What are the fees or staking requirements involved?** @@ -151,7 +151,7 @@ For [pooled staking services](/staking/pools/): **What user interfaces are supported?** -- i.e. Browser app, desktop app, mobile app, CLI +- i.e., Browser app, desktop app, mobile app, CLI **For node tooling, does the software provide an easy way to switch between clients?** From 5ab78ebc2188c5f443fd2ebc6288181fb55e9bc7 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:14:25 -0500 Subject: [PATCH 006/212] hardstops on design-princples/index --- public/content/contributing/design-principles/index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/public/content/contributing/design-principles/index.md b/public/content/contributing/design-principles/index.md index 4e3f4a90597..fa2176566f9 100644 --- a/public/content/contributing/design-principles/index.md +++ b/public/content/contributing/design-principles/index.md @@ -14,7 +14,7 @@ You should read these before you [contribute to ethereum.org](/contributing/). ## What are design principles? {#ways-to-contribute} -Don't worry, they're pretty simple! **Design principles** are a set of guidelines we refer to when designing (i.e. creating, maintaining or updating) something. +Don't worry, they're pretty simple! **Design principles** are a set of guidelines we refer to when designing (i.e., creating, maintaining or updating) something. In the context of ethereum.org these design principles are the foundation for what we want the website to represent and project to the world. They're both aspirational **and** functional. It's not just how the website _looks_, but also how it _works_ and even how it makes someone _feel._ Everything, from the colors to the page layouts to how we talk about Ethereum on the website should be informed by these principles. @@ -22,9 +22,9 @@ In the context of ethereum.org these design principles are the foundation for wh Let's look at an example. One of the principles is “Credible”, which means that we want visitors to the site to _feel_ and _know_ that the site is trustworthy - just like the wider Ethereum ecosystem. Within that principle, we have 3 functional “sub-principles” that we believe are actionable steps we can take to make the site credible: -- _“Fresh”_ i.e. keep the content up-to-date. -- _“Social Proof”_ i.e. show the size, diversity and activity of the ecosystem (you know: Ethereum upgrade progress, DeFi, gaming, all the hackathons, etc.) -- _“Consistent”_ i.e. consistency in the design of the site and the tone and accuracy of the writing. +- _“Fresh”_ i.e., keep the content up-to-date. +- _“Social Proof”_ i.e., show the size, diversity and activity of the ecosystem (you know: Ethereum upgrade progress, DeFi, gaming, all the hackathons, etc.) +- _“Consistent”_ i.e., consistency in the design of the site and the tone and accuracy of the writing. So when we're making design decisions, or copywriting decisions, we can then reference the “Credible” principle and ask: @@ -88,6 +88,6 @@ You can see our design principles in action [across our site](/). **Share your feedback on this document!** One of our proposed principles is “**Collaborative Improvement**” which means that we want the website to be the product of many contributors. So in the spirit of that principle, we want to share these design principles with the Ethereum community. -While these principles are focused on the ethereum.org website, we hope that many of them are representative of the values of the Ethereum ecosystem overall (e.g. you can see influence from the [principles of the Ethereum Whitepaper](https://github.com/ethereum/wiki/wiki/White-Paper#philosophy)). Maybe you even want to incorporate some of them into your own project! +While these principles are focused on the ethereum.org website, we hope that many of them are representative of the values of the Ethereum ecosystem overall (e.g., you can see influence from the [principles of the Ethereum Whitepaper](https://github.com/ethereum/wiki/wiki/White-Paper#philosophy)). Maybe you even want to incorporate some of them into your own project! Let us know your thoughts on [Discord server](https://discord.gg/ethereum-org) or by [creating an issue](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=). From 3a39f98a90777696c4cb8529266adbfa8100315d Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:16:29 -0500 Subject: [PATCH 007/212] hardstops on content-standardization/index --- .../style-guide/content-standardization/index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/public/content/contributing/style-guide/content-standardization/index.md b/public/content/contributing/style-guide/content-standardization/index.md index c01e9531cd2..3ba613e96b5 100644 --- a/public/content/contributing/style-guide/content-standardization/index.md +++ b/public/content/contributing/style-guide/content-standardization/index.md @@ -35,7 +35,7 @@ Ether is a common noun and should not be capitalized unless at the beginning of ### Mainnet {#mainnet} -When referring to the Ethereum Mainnet (i.e. not referring to a testnet) use the proper noun. Proper nouns help avoid confusion and build greater understanding. +When referring to the Ethereum Mainnet (i.e., not referring to a testnet) use the proper noun. Proper nouns help avoid confusion and build greater understanding. **Correct usage:** @@ -172,16 +172,16 @@ Use the "D-Mon-YYYY" format for dates. This format eliminates ambiguity between By adhering to these guidelines, we create a unified approach to presenting dates, fostering clarity and comprehension throughout Ethereum documentation. -### Hard stops (i.e., e.g.,) +### Hard stops (i.e., and e.g.,) When using abbreviations such as i.e., or e.g., it should include the comma after the period. This usage will allow for consistency and presentation. **Examples:** -- Preferred: i.e., the preferred usage -- Avoid: i.e. do not use +- Preferred: i.e., or e.g., the preferred usage +- Avoid: i.e. or e.g. do not use ### Linking to internal pages {#internal-links} -When linking to another page on Ethereum.org, use the relative path over the absolute path. Do not hard-code the language path (i.e. `/en/`) in any links. This maintains consistent functionality across different language versions of the site. +When linking to another page on Ethereum.org, use the relative path over the absolute path. Do not hard-code the language path (i.e., `/en/`) in any links. This maintains consistent functionality across different language versions of the site. ```md From 764429ae54e7ff6ca1e07cf59788ccf92ef769a8 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:17:19 -0500 Subject: [PATCH 008/212] hardstops on how-to-translate/index --- .../contributing/translation-program/how-to-translate/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/contributing/translation-program/how-to-translate/index.md b/public/content/contributing/translation-program/how-to-translate/index.md index da97d27e395..e261e0e2c8f 100644 --- a/public/content/contributing/translation-program/how-to-translate/index.md +++ b/public/content/contributing/translation-program/how-to-translate/index.md @@ -76,7 +76,7 @@ Want to learn more? Feel free to check out the [documentation on using the Crowd ### Review process {#review-process} -Once you've completed the translation (i.e. all files for a content bucket display 100%), our professional translation service will review (and potentially edit) the content. Once the review is complete (i.e. review progress is 100%), we will add it to the website. +Once you've completed the translation (i.e., all files for a content bucket display 100%), our professional translation service will review (and potentially edit) the content. Once the review is complete (i.e., review progress is 100%), we will add it to the website. Please do not use machine translation to translate the project. All the translations will be reviewed before being added to the website. If your suggested translations are found to be machine translated, they will be dismissed and contributors who use machine translation often will be removed from the project. From 46690cd603e1bc3c033c41bdb81dd06ed6022ce4 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:19:28 -0500 Subject: [PATCH 009/212] hardstops on translators-guide/index --- .../translation-program/translators-guide/index.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/public/content/contributing/translation-program/translators-guide/index.md b/public/content/contributing/translation-program/translators-guide/index.md index 39330d09d50..bcf739fee2b 100644 --- a/public/content/contributing/translation-program/translators-guide/index.md +++ b/public/content/contributing/translation-program/translators-guide/index.md @@ -50,7 +50,7 @@ All of the content should be translated using the correct writing system for you When translating the content, you should ensure that the translations are consistent and do not include any Latin characters. -A common misconception is that Ethereum should always be written in Latin. This is mostly incorrect, please use the spelling of Ethereum, native to your language (e.g. 以太坊 in Chinese, إيثيريوم in Arabic, etc.). +A common misconception is that Ethereum should always be written in Latin. This is mostly incorrect, please use the spelling of Ethereum, native to your language (e.g., 以太坊 in Chinese, إيثيريوم in Arabic, etc.). **The above doesn’t apply to languages, where proper names shouldn’t be translated as a rule.** @@ -122,7 +122,7 @@ The best way to handle links is to copy them directly from the source, either by ![Example of link.png](./example-of-link.png) -Links also appear in the source text in the form of tags (i.e. `<0>` ``). If you hover over the tag, the editor will show its full content - sometimes these tags will represent links. +Links also appear in the source text in the form of tags (i.e., `<0>` ``). If you hover over the tag, the editor will show its full content - sometimes these tags will represent links. It is very important to copy the links from the source and not change their order. @@ -166,7 +166,7 @@ In the example below, you can see that hovering over the `<0>` tag shows that it ## Short vs. full forms/abbreviations {#short-vs-full-forms} -There are a lot of abbreviations used on the website, e.g. dapps, NFT, DAO, DeFi, etc. These abbreviations are commonly used in English and most visitors to the website are familiar with them. +There are a lot of abbreviations used on the website, e.g., dapps, NFT, DAO, DeFi, etc. These abbreviations are commonly used in English and most visitors to the website are familiar with them. Since they usually don’t have established translations in other languages, the best way to approach these and similar terms is to provide a descriptive translation of the full form, and add the English abbreviation in brackets. @@ -192,7 +192,7 @@ The website contains numerous buttons, which should be translated differently th Button text can be identified by viewing the context screenshots, connected with most strings, or by checking the context in the editor, which includes the phrase ‘’button’’. -The translations for buttons should be as short as possible, to prevent formatting mismatches. Additionally, button translations should be imperative, i.e. present a command or request. +The translations for buttons should be as short as possible, to prevent formatting mismatches. Additionally, button translations should be imperative, i.e., present a command or request. ![How to find a button.png](./how-to-find-a-button.png) @@ -226,8 +226,8 @@ Some examples of what to be particularly mindful of: - Orthography rules define the use of spaces for each language. Because spaces are used everywhere, these rules are some of the most distinct, and spaces are some of the most mistranslated elements. - Some common differences in spacing between English and other languages: - - Space before units of measure and currencies (e.g. USD, EUR, kB, MB) - - Space before degree signs (e.g. °C, ℉) + - Space before units of measure and currencies (e.g., USD, EUR, kB, MB) + - Space before degree signs (e.g., °C, ℉) - Space before some punctuation marks, especially the ellipsis (…) - Space before and after slashes (/) From 5db21642a704fe7881281dc3ddb6a7e9151bfe12 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:20:25 -0500 Subject: [PATCH 010/212] hardstops on decentralized-identity/index --- public/content/decentralized-identity/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/decentralized-identity/index.md b/public/content/decentralized-identity/index.md index d8fba4c819c..933e68353c2 100644 --- a/public/content/decentralized-identity/index.md +++ b/public/content/decentralized-identity/index.md @@ -151,7 +151,7 @@ Here's an example to show how onchain attestations might work in practice: ### Soulbound tokens and identity {#soulbound} -[Soulbound tokens](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([non-transferable NFTs](/glossary/#nft)) could be used to collect information unique to a specific wallet. This effectively creates a unique onchain identity bound to a particular Ethereum address that could include tokens representing achievements (e.g. finishing some specific online course or passing a threshold score in a game) or community participation. +[Soulbound tokens](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([non-transferable NFTs](/glossary/#nft)) could be used to collect information unique to a specific wallet. This effectively creates a unique onchain identity bound to a particular Ethereum address that could include tokens representing achievements (e.g., finishing some specific online course or passing a threshold score in a game) or community participation. ## Use decentralized identity {#use-decentralized-identity} From e3d500834b20babbb088b03654c79c65b31d9c0a Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:21:19 -0500 Subject: [PATCH 011/212] hardstops on apis/backend/index --- public/content/developers/docs/apis/backend/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/docs/apis/backend/index.md b/public/content/developers/docs/apis/backend/index.md index 47219134ea6..d10d99b700f 100644 --- a/public/content/developers/docs/apis/backend/index.md +++ b/public/content/developers/docs/apis/backend/index.md @@ -4,7 +4,7 @@ description: An introduction to the Ethereum client APIs that let you interact w lang: en --- -In order for a software application to interact with the Ethereum blockchain (i.e. read blockchain data and/or send transactions to the network), it must connect to an Ethereum node. +In order for a software application to interact with the Ethereum blockchain (i.e., read blockchain data and/or send transactions to the network), it must connect to an Ethereum node. For this purpose, every Ethereum client implements the [JSON-RPC](/developers/docs/apis/json-rpc/) specification, so there is a uniform set of [methods](/developers/docs/apis/json-rpc/#json-rpc-methods) that applications can rely on. @@ -16,7 +16,7 @@ It might be helpful to understand the [Ethereum stack](/developers/docs/ethereum ## Why use a library? {#why-use-a-library} -These libraries abstract away much of the complexity of interacting directly with an Ethereum node. They also provide utility functions (e.g. converting ETH to Gwei) so as a developer you can spend less time dealing with the intricacies of Ethereum clients and more time focused on the unique functionality of your application. +These libraries abstract away much of the complexity of interacting directly with an Ethereum node. They also provide utility functions (e.g., converting ETH to Gwei) so as a developer you can spend less time dealing with the intricacies of Ethereum clients and more time focused on the unique functionality of your application. ## Available libraries {#available-libraries} From 3d5f72290936a05d831120f123edc698fd12f54c Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:21:57 -0500 Subject: [PATCH 012/212] hardstops on apis/javascript/index --- public/content/developers/docs/apis/javascript/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/developers/docs/apis/javascript/index.md b/public/content/developers/docs/apis/javascript/index.md index 6613422cf87..c62d205269d 100644 --- a/public/content/developers/docs/apis/javascript/index.md +++ b/public/content/developers/docs/apis/javascript/index.md @@ -4,13 +4,13 @@ description: An introduction to the JavaScript client libraries that let you int lang: en --- -In order for a web app to interact with the Ethereum blockchain (i.e. read blockchain data and/or send transactions to the network), it must connect to an Ethereum node. +In order for a web app to interact with the Ethereum blockchain (i.e., read blockchain data and/or send transactions to the network), it must connect to an Ethereum node. For this purpose, every Ethereum client implements the [JSON-RPC](/developers/docs/apis/json-rpc/) specification, so there are a uniform set of [methods](/developers/docs/apis/json-rpc/#json-rpc-methods) that applications can rely on. If you want to use JavaScript to connect with an Ethereum node, it's possible to use vanilla JavaScript but several convenience libraries exist within the ecosystem that make this much easier. With these libraries, developers can write intuitive, one-line methods to initialize JSON-RPC requests (under the hood) that interact with Ethereum. -Please note that since [The Merge](/roadmap/merge/), two connected pieces of Ethereum software - an execution client and a consensus client - are required to run a node. Please ensure your node includes both an execution and consensus client. If your node is not on your local machine (e.g. your node is running on an AWS instance) update the IP addresses in the tutorial accordingly. For more information please see our page on [running a node](/developers/docs/nodes-and-clients/run-a-node/). +Please note that since [The Merge](/roadmap/merge/), two connected pieces of Ethereum software - an execution client and a consensus client - are required to run a node. Please ensure your node includes both an execution and consensus client. If your node is not on your local machine (e.g., your node is running on an AWS instance) update the IP addresses in the tutorial accordingly. For more information please see our page on [running a node](/developers/docs/nodes-and-clients/run-a-node/). ## Prerequisites {#prerequisites} @@ -18,7 +18,7 @@ As well as understanding JavaScript, it might be helpful to understand the [Ethe ## Why use a library? {#why-use-a-library} -These libraries abstract away much of the complexity of interacting directly with an Ethereum node. They also provide utility functions (e.g. converting ETH to Gwei) so as a developer you can spend less time dealing with the intricacies of Ethereum clients and more time focused on the unique functionality of your application. +These libraries abstract away much of the complexity of interacting directly with an Ethereum node. They also provide utility functions (e.g., converting ETH to Gwei) so as a developer you can spend less time dealing with the intricacies of Ethereum clients and more time focused on the unique functionality of your application. ## Library features {#library-features} From a70078c6baeaa1f988680d56b8cc5c9ff6d33498 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:23:11 -0500 Subject: [PATCH 013/212] hardstops on attack-and-defense/index --- .../consensus-mechanisms/pos/attack-and-defense/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md index d51c63752c4..66b7a5a7534 100644 --- a/public/content/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md +++ b/public/content/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md @@ -12,7 +12,7 @@ Some basic knowledge of [proof-of-stake](/developers/docs/consensus-mechanisms/p ## What do attackers want? {#what-do-attackers-want} -A common misconception is that a successful attacker can generate new ether, or drain ether from arbitrary accounts. Neither of these are possible because all transactions are executed by all the execution clients on the network. They must satisfy basic conditions of validity (e.g. transactions are signed by sender’s private key, sender has sufficient balance, etc) or else they simply revert. There are three classes of outcome that an attacker might realistically target: reorgs, double finality or finality delay. +A common misconception is that a successful attacker can generate new ether, or drain ether from arbitrary accounts. Neither of these are possible because all transactions are executed by all the execution clients on the network. They must satisfy basic conditions of validity (e.g., transactions are signed by sender’s private key, sender has sufficient balance, etc) or else they simply revert. There are three classes of outcome that an attacker might realistically target: reorgs, double finality or finality delay. A **“reorg”** is a reshuffling of blocks into a new order, perhaps with some addition or subtraction of blocks in the canonical chain. A malicious reorg might ensure specific blocks are included or excluded, allowing double-spending or value extraction by front-running and back-running transactions (MEV). Re-orgs could also be used to prevent certain transactions from being included in the canonical chain - a form of censorship. The most extreme form of reorg is “finality reversion” which removes or replaces blocks that have previously been finalized. This is only possible if more than ⅓ of the total staked ether is destroyed by the attacker - this guarantee is known as “economic finality” - more on this later. @@ -71,7 +71,7 @@ Both bouncing and balancing attacks rely upon the attacker having very fine cont Combined, these measures create a scenario in which an honest block proposer emits their block very rapidly after the start of the slot, then there is a period of ~1/3 of a slot (4 seconds) where that new block might cause the fork-choice algorithm to switch to another chain. After that same deadline, attestations that arrive from slow validators are down-weighted compared to those that arrived earlier. This strongly favors prompt proposers and validators in determining the head of the chain and substantially reduces the likelihood of a successful balancing or bouncing attack. -It is worth noting, that proposer boosting alone only defends against “cheap reorgs”, i.e. those attempted by an attacker with a small stake. In fact, proposer-boosting itself can be gamed by larger stakeholders. The authors of [this post](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) describe how an attacker with 7% of the stake can deploy their votes strategically to trick honest validators to build on their fork, reorging out an honest block. This attack was devised assuming ideal latency conditions that are very unlikely. The odds are still very long for the attacker, and the greater stake also means more capital at risk and a stronger economic disincentive. +It is worth noting, that proposer boosting alone only defends against “cheap reorgs”, i.e., those attempted by an attacker with a small stake. In fact, proposer-boosting itself can be gamed by larger stakeholders. The authors of [this post](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) describe how an attacker with 7% of the stake can deploy their votes strategically to trick honest validators to build on their fork, reorging out an honest block. This attack was devised assuming ideal latency conditions that are very unlikely. The odds are still very long for the attacker, and the greater stake also means more capital at risk and a stronger economic disincentive. A [balancing attack specifically targeting the LMD rule](https://ethresear.ch/t/balancing-attack-lmd-edition/11853) was also proposed, which was suggested to be viable in spite of proposer boosting. An attacker sets up two competing chains by equivocating their block proposal and propagating each block to about half the network each, setting up an approximate balance between the forks. Then, the colluding validators equivocate their votes, timing it so that half the network receive their votes for Fork `A` first and the other half receives their votes for Fork `B` first. Since the LMD rule discards the second attestation and keeps only the first for each validator, half the network sees votes for `A` and none for `B`, the other half sees votes for `B` and none for `A`. The authors describe the LMD rule giving the adversary “remarkable power” to mount a balancing attack. @@ -105,7 +105,7 @@ All of the attacks mentioned previously in this article become more likely to su The purpose of the inactivity leak is to get the chain finalizing again. However, the attacker also loses a portion of their staked ether. Persistent inactivity across validators representing 33% of the total staked ether is very expensive even though the validators are not slashed. -Assuming that the Ethereum network is asynchronous (i.e. there are delays between messages being sent and received), an attacker controlling 34% of the total stake could cause double finality. This is because the attacker can equivocate when they are chosen to be a block producer, then double vote with all of their validators. This creates a situation where a fork of the blockchain exists, each with 34% of the staked ether voting for it. Each fork only requires 50% of the remaining validators to vote in its favor for both forks to be supported by a supermajority, in which case both chains can finalize (because 34% of attackers validators + half of remaining 66% = 67% on each fork). The competing blocks would each have to be received by about 50% of the honest validators so this attack is viable only when the attacker has some degree of control over the timing of messages propagating over the network so that they can nudge half the honest validators onto each chain. The attacker would necessarily destroy their entire stake (34% of ~10 million ether with today’s validator set) to achieve this double finality because 34% of their validators would be double-voting simultaneously - a slashable offense with the maximum correlation penalty. The defense against this attack is the very large cost of destroying 34% of the total staked ether. Recovering from this attack would require the Ethereum community to coordinate “out-of-band” and agree to follow one or other of the forks and ignore the other. +Assuming that the Ethereum network is asynchronous (i.e., there are delays between messages being sent and received), an attacker controlling 34% of the total stake could cause double finality. This is because the attacker can equivocate when they are chosen to be a block producer, then double vote with all of their validators. This creates a situation where a fork of the blockchain exists, each with 34% of the staked ether voting for it. Each fork only requires 50% of the remaining validators to vote in its favor for both forks to be supported by a supermajority, in which case both chains can finalize (because 34% of attackers validators + half of remaining 66% = 67% on each fork). The competing blocks would each have to be received by about 50% of the honest validators so this attack is viable only when the attacker has some degree of control over the timing of messages propagating over the network so that they can nudge half the honest validators onto each chain. The attacker would necessarily destroy their entire stake (34% of ~10 million ether with today’s validator set) to achieve this double finality because 34% of their validators would be double-voting simultaneously - a slashable offense with the maximum correlation penalty. The defense against this attack is the very large cost of destroying 34% of the total staked ether. Recovering from this attack would require the Ethereum community to coordinate “out-of-band” and agree to follow one or other of the forks and ignore the other. ### Attackers using ~50% of the total stake {#attackers-with-50-stake} @@ -117,7 +117,7 @@ At >50% of the total stake the attacker could dominate the fork choice algorithm ### Attackers using >=66% of the total stake {#attackers-with-66-stake} -An attacker with 66% or more of the total staked ether can finalize their preferred chain without having to coerce any honest validators. The attacker can simply vote for their preferred fork and then finalize it, simply because they can vote with a dishonest supermajority. As the supermajority stakeholder, the attacker would always control the contents of the finalized blocks, with the power to spend, rewind and spend again, censor certain transactions and reorg the chain at will. By purchasing additional ether to control 66% rather than 51%, the attacker is effectively buying the ability to do ex post reorgs and finality reversions (i.e. change the past as well as control the future). The only real defenses here are the enormous cost of 66% of the total staked ether, and the option to fall back to the social layer to coordinate adoption of an alternative fork. We can explore this in more detail in the next section. +An attacker with 66% or more of the total staked ether can finalize their preferred chain without having to coerce any honest validators. The attacker can simply vote for their preferred fork and then finalize it, simply because they can vote with a dishonest supermajority. As the supermajority stakeholder, the attacker would always control the contents of the finalized blocks, with the power to spend, rewind and spend again, censor certain transactions and reorg the chain at will. By purchasing additional ether to control 66% rather than 51%, the attacker is effectively buying the ability to do ex post reorgs and finality reversions (i.e., change the past as well as control the future). The only real defenses here are the enormous cost of 66% of the total staked ether, and the option to fall back to the social layer to coordinate adoption of an alternative fork. We can explore this in more detail in the next section. ## People: the last line of defense {#people-the-last-line-of-defense} From 185e17706a26cc94808b21e80b283fdc1a884e4f Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:23:55 -0500 Subject: [PATCH 014/212] hardstops on attestations/index --- .../docs/consensus-mechanisms/pos/attestations/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/developers/docs/consensus-mechanisms/pos/attestations/index.md index bf9bd6eb646..a58b0ed283f 100644 --- a/public/content/developers/docs/consensus-mechanisms/pos/attestations/index.md +++ b/public/content/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -12,7 +12,7 @@ Every [epoch](/glossary/#epoch) (6.4 minutes) a validator proposes an attestatio The attestation contains the following components: -- `aggregation_bits`: a bitlist of validators where the position maps to the validator index in their committee; the value (0/1) indicates whether the validator signed the `data` (i.e. whether they are active and agree with the block proposer) +- `aggregation_bits`: a bitlist of validators where the position maps to the validator index in their committee; the value (0/1) indicates whether the validator signed the `data` (i.e., whether they are active and agree with the block proposer) - `data`: details relating to the attestation, as defined below - `signature`: a BLS signature that aggregates the signatures of individual validators From f5341d43c3756572157a8677ddbfe684058e1464 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:24:30 -0500 Subject: [PATCH 015/212] hardstops on faqs/index --- .../developers/docs/consensus-mechanisms/pos/faqs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/developers/docs/consensus-mechanisms/pos/faqs/index.md index bb4b0c48da5..3e48ddee292 100644 --- a/public/content/developers/docs/consensus-mechanisms/pos/faqs/index.md +++ b/public/content/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -167,6 +167,6 @@ The Merge was the moment when Ethereum switched off its proof-of-work-based cons ## What are liveness and safety? {#what-are-liveness-and-safety} -Liveness and safety are the two fundamental security concerns for a blockchain. Liveness is the availability of a finalizing chain. If the chain stops finalizing or users are not able to access it easily, those are liveness failures. Extremely high cost of access could also be considered a liveness failure. Safety refers to how difficult it is to attack the chain - i.e. finalize conflicting checkpoints. +Liveness and safety are the two fundamental security concerns for a blockchain. Liveness is the availability of a finalizing chain. If the chain stops finalizing or users are not able to access it easily, those are liveness failures. Extremely high cost of access could also be considered a liveness failure. Safety refers to how difficult it is to attack the chain - i.e., finalize conflicting checkpoints. [Read more in the Casper paper](https://arxiv.org/pdf/1710.09437.pdf) From eba60c9691239da54f27570bdeeabfbbd114d4d4 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:25:28 -0500 Subject: [PATCH 016/212] hardstops on gasper/index --- .../developers/docs/consensus-mechanisms/pos/gasper/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/developers/docs/consensus-mechanisms/pos/gasper/index.md index f222dd21e5a..3f049723030 100644 --- a/public/content/developers/docs/consensus-mechanisms/pos/gasper/index.md +++ b/public/content/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -23,7 +23,7 @@ Finality is a property of certain blocks that means they cannot be reverted unle 1. Two-thirds of the total staked ether must have voted in favor of that block's inclusion in the canonical chain. This condition upgrades the block to "justified". Justified blocks are unlikely to be reverted, but they can be under certain conditions. 2. When another block is justified on top of a justified block, it is upgraded to "finalized". Finalizing a block is a commitment to include the block in the canonical chain. It cannot be reverted unless an attacker destroys millions of ether (billions of $USD). -These block upgrades do not happen in every slot. Instead, only epoch-boundary blocks can be justified and finalized. These blocks are known as "checkpoints". Upgrading considers pairs of checkpoints. A "supermajority link" must exist between two successive checkpoints (i.e. two-thirds of the total staked ether voting that checkpoint B is the correct descendant of checkpoint A) to upgrade the less recent checkpoint to finalized and the more recent block to justified. +These block upgrades do not happen in every slot. Instead, only epoch-boundary blocks can be justified and finalized. These blocks are known as "checkpoints". Upgrading considers pairs of checkpoints. A "supermajority link" must exist between two successive checkpoints (i.e., two-thirds of the total staked ether voting that checkpoint B is the correct descendant of checkpoint A) to upgrade the less recent checkpoint to finalized and the more recent block to justified. Because finality requires a two-thirds agreement that a block is canonical, an attacker cannot possibly create an alternative finalized chain without: From d57d0a9e6442fa09154b71908bf084915bffc5b0 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:26:11 -0500 Subject: [PATCH 017/212] hardstops on rewards-and-penalties/index --- .../consensus-mechanisms/pos/rewards-and-penalties/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md index 065eac86d8f..9054a39f90e 100644 --- a/public/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md +++ b/public/content/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -58,7 +58,7 @@ Block proposers receive `8 / 64 * base_reward` for **each valid attestation** in So far we have considered perfectly well-behaved validators, but what about validators that do not make timely head, source and target votes or do so slowly? -The penalties for missing the target and source votes are equal to the rewards the attestor would have received had they submitted them. This means that instead of having the reward added to their balance, they have an equal value removed from their balance. There is no penalty for missing the head vote (i.e. head votes are only rewarded, never penalized). There is no penalty associated with the `inclusion_delay` - the reward will simply not be added to the validator's balance. There is also no penalty for failing to propose a block. +The penalties for missing the target and source votes are equal to the rewards the attestor would have received had they submitted them. This means that instead of having the reward added to their balance, they have an equal value removed from their balance. There is no penalty for missing the head vote (i.e., head votes are only rewarded, never penalized). There is no penalty associated with the `inclusion_delay` - the reward will simply not be added to the validator's balance. There is also no penalty for failing to propose a block. Read more about rewards and penalties in the [consensus specs](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). Rewards and penalties were adjusted in the Bellatrix upgrade - watch Danny Ryan and Vitalik discuss this in this [Peep an EIP video](https://www.youtube.com/watch?v=iaAEGs1DMgQ). @@ -70,7 +70,7 @@ Slashing is a more severe action that results in the forceful removal of a valid - By attesting to a block that "surrounds" another one (effectively changing history) - By "double voting" by attesting to two candidates for the same block -If these actions are detected, the validator is slashed. This means that 0.0078125 is immediately burned for a 32 ETH validator (scaled linearly with active balance), then a 36 day removal period begins. During this removal period the validator's stake gradually bleeds away. At the mid-point (Day 18) an additional penalty is applied whose magnitude scales with the total staked ether of all slashed validators in the 36 days prior to the slashing event. This means that when more validators are slashed, the magnitude of the slash increases. The maximum slash is the full effective balance of all slashed validators (i.e. if there are lots of validators being slashed they could lose their entire stake). On the other hand, a single, isolated slashing event only burns a small portion of the validator's stake. This midpoint penalty that scales with the number of slashed validators is called the "correlation penalty". +If these actions are detected, the validator is slashed. This means that 0.0078125 is immediately burned for a 32 ETH validator (scaled linearly with active balance), then a 36 day removal period begins. During this removal period the validator's stake gradually bleeds away. At the mid-point (Day 18) an additional penalty is applied whose magnitude scales with the total staked ether of all slashed validators in the 36 days prior to the slashing event. This means that when more validators are slashed, the magnitude of the slash increases. The maximum slash is the full effective balance of all slashed validators (i.e., if there are lots of validators being slashed they could lose their entire stake). On the other hand, a single, isolated slashing event only burns a small portion of the validator's stake. This midpoint penalty that scales with the number of slashed validators is called the "correlation penalty". ## Inactivity leak {#inactivity-leak} From 40d2e327ea0f278ec09472b3b2147bdb9fffcc95 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:26:49 -0500 Subject: [PATCH 018/212] hardstops on pow/index --- .../content/developers/docs/consensus-mechanisms/pow/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/consensus-mechanisms/pow/index.md b/public/content/developers/docs/consensus-mechanisms/pow/index.md index 62f44114d8c..352259ebd9e 100644 --- a/public/content/developers/docs/consensus-mechanisms/pow/index.md +++ b/public/content/developers/docs/consensus-mechanisms/pow/index.md @@ -16,7 +16,7 @@ To better understand this page, we recommend you first read up on [transactions] ## What is Proof-of-work (PoW)? {#what-is-pow} -Nakamoto consensus, which utilizes proof-of-work, is the mechanism that once allowed the decentralized Ethereum network to come to consensus (i.e. all nodes agree) on things like account balances and the order of transactions. This prevented users from "double spending" their coins and ensured that the Ethereum chain was tremendously difficult to attack or manipulate. These security properties now come from proof-of-stake instead using the consensus mechanism known as [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/). +Nakamoto consensus, which utilizes proof-of-work, is the mechanism that once allowed the decentralized Ethereum network to come to consensus (i.e., all nodes agree) on things like account balances and the order of transactions. This prevented users from "double spending" their coins and ensured that the Ethereum chain was tremendously difficult to attack or manipulate. These security properties now come from proof-of-stake instead using the consensus mechanism known as [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/). ## Proof-of-work and mining {#pow-and-mining} From 80a02b6ad68b8db197b3b3c5eea5624fbe08a5d2 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:27:14 -0500 Subject: [PATCH 019/212] hardstops on mining/index --- .../developers/docs/consensus-mechanisms/pow/mining/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/developers/docs/consensus-mechanisms/pow/mining/index.md index 0cc31051894..42554a5bb2a 100644 --- a/public/content/developers/docs/consensus-mechanisms/pow/mining/index.md +++ b/public/content/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -47,7 +47,7 @@ The following provides an overview of how transactions were mined in Ethereum pr 2. The user broadcasts the transaction request to the entire Ethereum network from some [node](/developers/docs/nodes-and-clients/). 3. Upon hearing about the new transaction request, each node in the Ethereum network adds the request to their local mempool, a list of all transaction requests they’ve heard about that have not yet been committed to the blockchain in a block. 4. At some point, a mining node aggregates several dozen or hundred transaction requests into a potential [block](/developers/docs/blocks/), in a way that maximizes the [transaction fees](/developers/docs/gas/) they earn while still staying under the block gas limit. The mining node then: - 1. Verifies the validity of each transaction request (i.e. no one is trying to transfer ether out of an account they haven’t produced a signature for, the request is not malformed, etc.), and then executes the code of the request, altering the state of their local copy of the EVM. The miner awards the transaction fee for each such transaction request to their own account. + 1. Verifies the validity of each transaction request (i.e., no one is trying to transfer ether out of an account they haven’t produced a signature for, the request is not malformed, etc.), and then executes the code of the request, altering the state of their local copy of the EVM. The miner awards the transaction fee for each such transaction request to their own account. 2. Begins the process of producing the proof-of-work “certificate of legitimacy” for the potential block, once all transaction requests in the block have been verified and executed on the local EVM copy. 5. Eventually, a miner will finish producing a certificate for a block which includes our specific transaction request. The miner then broadcasts the completed block, which includes the certificate and a checksum of the claimed new EVM state. 6. Other nodes hear about the new block. They verify the certificate, execute all transactions on the block themselves (including the transaction originally broadcasted by our user), and verify that the checksum of their new EVM state after the execution of all transactions matches the checksum of the state claimed by the miner’s block. Only then do these nodes append this block to the tail of their blockchain, and accept the new EVM state as the canonical state. From 8893850e35871bede6b21ec7b68b918877897c94 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:27:48 -0500 Subject: [PATCH 020/212] hardstops on mining-algorithms/index --- .../pow/mining/mining-algorithms/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md index 280eba061a3..d5785eda687 100644 --- a/public/content/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md +++ b/public/content/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -20,9 +20,9 @@ Dagger Hashimoto was a precursor research algorithm for Ethereum mining that Eth [Dagger](http://www.hashcash.org/papers/dagger.html) involves the generation of a [Directed Acyclic Graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph), random slices of which get hashed together. The core principle is that each nonce only requires a small portion of a large total data tree. Recomputing the subtree for each nonce is prohibitive for mining - hence the need to store the tree - but okay for a single nonce’s worth of verification. Dagger was designed to be an alternative to existing algorithms like Scrypt, which are memory-hard but difficult to verify when their memory-hardness increases to genuinely secure levels. However, Dagger was vulnerable to shared memory hardware acceleration and dropped in favor of other avenues of research. -[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) is an algorithm that adds ASIC-resistance by being I/O bound (i.e. memory reads are the limiting factor in the mining process). The theory is that RAM is more available than computation; billions of dollars worth of research have already investigated optimizing RAM for different use cases, which often involve near-random access patterns (hence “random access memory”). As a result, existing RAM is likely to be moderately close to optimal for evaluating the algorithm. Hashimoto uses the blockchain as a source of data, simultaneously satisfying (1) and (3) above. +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) is an algorithm that adds ASIC-resistance by being I/O bound (i.e., memory reads are the limiting factor in the mining process). The theory is that RAM is more available than computation; billions of dollars worth of research have already investigated optimizing RAM for different use cases, which often involve near-random access patterns (hence “random access memory”). As a result, existing RAM is likely to be moderately close to optimal for evaluating the algorithm. Hashimoto uses the blockchain as a source of data, simultaneously satisfying (1) and (3) above. -Dagger-Hashimoto used amended versions of the Dagger and Hashimoto algorithms. The difference between Dagger Hashimoto and Hashimoto is that, instead of using the blockchain as a data source, Dagger Hashimoto uses a custom-generated data set, which updates based on block data every N blocks. The data set is generated using the Dagger algorithm, allowing for efficiently calculating a subset specific to every nonce for the light client verification algorithm. The difference between Dagger Hashimoto and Dagger is that, unlike in the original Dagger, the dataset used to query the block is semi-permanent, only being updated at occasional intervals (e.g. once per week). This means that the portion of the effort of generating the dataset is close to zero, so Sergio Lerner’s arguments regarding shared memory speedups become negligible. +Dagger-Hashimoto used amended versions of the Dagger and Hashimoto algorithms. The difference between Dagger Hashimoto and Hashimoto is that, instead of using the blockchain as a data source, Dagger Hashimoto uses a custom-generated data set, which updates based on block data every N blocks. The data set is generated using the Dagger algorithm, allowing for efficiently calculating a subset specific to every nonce for the light client verification algorithm. The difference between Dagger Hashimoto and Dagger is that, unlike in the original Dagger, the dataset used to query the block is semi-permanent, only being updated at occasional intervals (e.g., once per week). This means that the portion of the effort of generating the dataset is close to zero, so Sergio Lerner’s arguments regarding shared memory speedups become negligible. More on [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). From b2684090d37079defbe9b9140a72800719784592 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:32:35 -0500 Subject: [PATCH 021/212] hardstops on data-availability/index --- public/content/developers/docs/data-availability/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/docs/data-availability/index.md b/public/content/developers/docs/data-availability/index.md index f56bf33373b..93110b47b58 100644 --- a/public/content/developers/docs/data-availability/index.md +++ b/public/content/developers/docs/data-availability/index.md @@ -46,7 +46,7 @@ The way these fraud proofs work is that a full node, seeing an invalid state tra This relies on full nodes having access to full transaction data. An attacker who broadcasts a bad block header and also fails to make the transaction data available would be able to prevent full nodes from generating fraud proofs. The full nodes might be able to signal a warning about a bad block, but they couldn't back up their warning with proof, because the data wasn't made available to generate the proof from! -The solution to this data availability problem is DAS. Light nodes download very small random chunks of the full state data and use the samples to verify that the full data set is available. The actual likelihood of incorrectly assuming full data availability after downloading N random chunks can be calculated ([for 100 chunks the chance is 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), i.e. incredibly unlikely). +The solution to this data availability problem is DAS. Light nodes download very small random chunks of the full state data and use the samples to verify that the full data set is available. The actual likelihood of incorrectly assuming full data availability after downloading N random chunks can be calculated ([for 100 chunks the chance is 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), i.e., incredibly unlikely). Even in this scenario, attacks that withhold just a few bytes could feasibly go unnoticed by clients making random data requests. Erasure coding fixes this by reconstructing small missing pieces of data that can be used to check proposed state changes. A fraud proof could then be constructed using the reconstructed data, preventing light nodes from accepting bad headers. @@ -58,7 +58,7 @@ Even in this scenario, attacks that withhold just a few bytes could feasibly go However, it is only possible to trust the 'summary' transactions posted to Ethereum if the state change proposed can be independently verified and confirmed to be the result of applying all the individual offchain transactions. If rollup operators do not make the transaction data available for this verification, then they could send incorrect data to Ethereum. -[Optimistic rollups](/developers/docs/scaling/optimistic-rollups/) post compressed transaction data to Ethereum and wait for some amount of time (typically 7 days) to allow independent verifiers to check the data. If anyone identifies a problem, they can generate a fraud-proof and use it to challenge the rollup. This would cause the chain to roll back and omit the invalid block. This is only possible if data is available. Currently, there are two ways that optimistic rollups post transaction data to L1. Some rollups make data permanently available as `CALLDATA` which lives permanently onchain. With the implementation of EIP-4844, some rollups post their transaction data to cheaper blob storage instead. This is not permanent storage. Independent verifiers have to query the blobs and raise their challenges within ~18 days before the data is deleted from Ethereum layer-1. Data availability is only guaranteed by the Ethereum protocol for that short fixed window. After that, it becomes the responsibility of other entities in the Ethereum ecosystem. Any node can verify data availability using DAS, i.e. by downloading small, random samples of the blob data. +[Optimistic rollups](/developers/docs/scaling/optimistic-rollups/) post compressed transaction data to Ethereum and wait for some amount of time (typically 7 days) to allow independent verifiers to check the data. If anyone identifies a problem, they can generate a fraud-proof and use it to challenge the rollup. This would cause the chain to roll back and omit the invalid block. This is only possible if data is available. Currently, there are two ways that optimistic rollups post transaction data to L1. Some rollups make data permanently available as `CALLDATA` which lives permanently onchain. With the implementation of EIP-4844, some rollups post their transaction data to cheaper blob storage instead. This is not permanent storage. Independent verifiers have to query the blobs and raise their challenges within ~18 days before the data is deleted from Ethereum layer-1. Data availability is only guaranteed by the Ethereum protocol for that short fixed window. After that, it becomes the responsibility of other entities in the Ethereum ecosystem. Any node can verify data availability using DAS, i.e., by downloading small, random samples of the blob data. [Zero-knowledge (ZK) rollups](/developers/docs/scaling/zk-rollups) don't need to post transaction data since [zero-knowledge validity proofs](/glossary/#zk-proof) guarantee the correctness of state transitions. However, data availability is still an issue because we can't guarantee the functionality of the ZK-rollup (or interact with it) without access to its state data. For example, users cannot know their balances if an operator withholds details about the rollup’s state. Also, they cannot perform state updates using information contained in a newly added block. From 24b68068cd9b19e5823f5d9c0a69b42356cb6b62 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:33:21 -0500 Subject: [PATCH 022/212] hardstops on rlp/index --- .../docs/data-structures-and-encoding/rlp/index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/public/content/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/developers/docs/data-structures-and-encoding/rlp/index.md index 890c86d8cc4..0370d61c4f2 100644 --- a/public/content/developers/docs/data-structures-and-encoding/rlp/index.md +++ b/public/content/developers/docs/data-structures-and-encoding/rlp/index.md @@ -5,7 +5,7 @@ lang: en sidebarDepth: 2 --- -Recursive Length Prefix (RLP) serialization is used extensively in Ethereum's execution clients. RLP standardizes the transfer of data between nodes in a space-efficient format. The purpose of RLP is to encode arbitrarily nested arrays of binary data, and RLP is the primary encoding method used to serialize objects in Ethereum's execution layer. The main purpose of RLP is to encode structure; with the exception of positive integers, RLP delegates encoding specific data types (e.g. strings, floats) to higher-order protocols. Positive integers must be represented in big-endian binary form with no leading zeroes (thus making the integer value zero equivalent to the empty byte array). Deserialized positive integers with leading zeroes must be treated as invalid by any higher-order protocol using RLP. +Recursive Length Prefix (RLP) serialization is used extensively in Ethereum's execution clients. RLP standardizes the transfer of data between nodes in a space-efficient format. The purpose of RLP is to encode arbitrarily nested arrays of binary data, and RLP is the primary encoding method used to serialize objects in Ethereum's execution layer. The main purpose of RLP is to encode structure; with the exception of positive integers, RLP delegates encoding specific data types (e.g., strings, floats) to higher-order protocols. Positive integers must be represented in big-endian binary form with no leading zeroes (thus making the integer value zero equivalent to the empty byte array). Deserialized positive integers with leading zeroes must be treated as invalid by any higher-order protocol using RLP. More information in [the Ethereum yellow paper (Appendix B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). @@ -18,7 +18,7 @@ To use RLP to encode a dictionary, the two suggested canonical forms are: The RLP encoding function takes in an item. An item is defined as follows： -- a string (i.e. byte array) is an item +- a string (i.e., byte array) is an item - a list of items is an item - a positive integer is an item @@ -39,7 +39,7 @@ RLP encoding is defined as follows: - Otherwise, if a string is 0-55 bytes long, the RLP encoding consists of a single byte with value **0x80** (dec. 128) plus the length of the string followed by the string. The range of the first byte is thus `[0x80, 0xb7]` (dec. `[128, 183]`). - If a string is more than 55 bytes long, the RLP encoding consists of a single byte with value **0xb7** (dec. 183) plus the length in bytes of the length of the string in binary form, followed by the length of the string, followed by the string. For example, a 1024 byte long string would be encoded as `\xb9\x04\x00` (dec. `185, 4, 0`) followed by the string. Here, `0xb9` (183 + 2 = 185) as the first byte, followed by the 2 bytes `0x0400` (dec. 1024) that denote the length of the actual string. The range of the first byte is thus `[0xb8, 0xbf]` (dec. `[184, 191]`). - If a string is 2^64 bytes long, or longer, it may not be encoded. -- If the total payload of a list (i.e. the combined length of all its items being RLP encoded) is 0-55 bytes long, the RLP encoding consists of a single byte with value **0xc0** plus the length of the payload followed by the concatenation of the RLP encodings of the items. The range of the first byte is thus `[0xc0, 0xf7]` (dec. `[192, 247]`). +- If the total payload of a list (i.e., the combined length of all its items being RLP encoded) is 0-55 bytes long, the RLP encoding consists of a single byte with value **0xc0** plus the length of the payload followed by the concatenation of the RLP encodings of the items. The range of the first byte is thus `[0xc0, 0xf7]` (dec. `[192, 247]`). - If the total payload of a list is more than 55 bytes long, the RLP encoding consists of a single byte with value **0xf7** plus the length in bytes of the length of the payload in binary form, followed by the length of the payload, followed by the concatenation of the RLP encodings of the items. The range of the first byte is thus `[0xf8, 0xff]` (dec. `[248, 255]`). In code, this is: @@ -87,7 +87,7 @@ def to_binary(x): According to the rules and process of RLP encoding, the input of RLP decode is regarded as an array of binary data. The RLP decoding process is as follows: -1. according to the first byte (i.e. prefix) of input data and decoding the data type, the length of the actual data and offset; +1. according to the first byte (i.e., prefix) of input data and decoding the data type, the length of the actual data and offset; 2. according to the type and offset of data, decode the data correspondingly, respecting the minimal encoding rule for positive integers; @@ -95,7 +95,7 @@ According to the rules and process of RLP encoding, the input of RLP decode is r Among them, the rules of decoding data types and offset is as follows: -1. the data is a string if the range of the first byte (i.e. prefix) is [0x00, 0x7f], and the string is the first byte itself exactly; +1. the data is a string if the range of the first byte (i.e., prefix) is [0x00, 0x7f], and the string is the first byte itself exactly; 2. the data is a string if the range of the first byte is [0x80, 0xb7], and the string whose length is equal to the first byte minus 0x80 follows the first byte; From 54c815221d71fbcb75ec495424c565589311ee6c Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:34:00 -0500 Subject: [PATCH 023/212] hardstops on ssz/index --- .../developers/docs/data-structures-and-encoding/ssz/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/developers/docs/data-structures-and-encoding/ssz/index.md index 26aef12220e..8175b48a4e6 100644 --- a/public/content/developers/docs/data-structures-and-encoding/ssz/index.md +++ b/public/content/developers/docs/data-structures-and-encoding/ssz/index.md @@ -16,7 +16,7 @@ SSZ is a serialization scheme that is not self-describing - rather it relies on - unsigned integers - Booleans -For complex "composite" types, serialization is more complicated because the composite type contains multiple elements that might have different types or different sizes, or both. Where these objects all have fixed lengths (i.e. the size of the elements is always going to be constant irrespective of their actual values) the serialization is simply a conversion of each element in the composite type ordered into little-endian bytestrings. These bytestrings are joined together. The serialized object has the bytelist representation of the fixed-length elements in the same order as they appear in the deserialized object. +For complex "composite" types, serialization is more complicated because the composite type contains multiple elements that might have different types or different sizes, or both. Where these objects all have fixed lengths (i.e., the size of the elements is always going to be constant irrespective of their actual values) the serialization is simply a conversion of each element in the composite type ordered into little-endian bytestrings. These bytestrings are joined together. The serialized object has the bytelist representation of the fixed-length elements in the same order as they appear in the deserialized object. For types with variable lengths, the actual data gets replaced by an "offset" value in that element's position in the serialized object. The actual data gets added to a heap at the end of the serialized object. The offset value is the index for the start of the actual data in the heap, acting as a pointer to the relevant bytes. From 07408244db65b96193d4e5f06a7405b307b99490 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:34:37 -0500 Subject: [PATCH 024/212] hardstops on web3-secret-storage/index --- .../data-structures-and-encoding/web3-secret-storage/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md b/public/content/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md index c94b8d51af6..b1ce9d1a4b0 100644 --- a/public/content/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md +++ b/public/content/developers/docs/data-structures-and-encoding/web3-secret-storage/index.md @@ -46,7 +46,7 @@ For PBKDF2, the kdfparams include: - `salt`: salt passed to PBKDF; - `dklen`: length for the derived key. Must be >= 32. -Once the file's key has been derived, it should be verified through the derivation of the MAC. The MAC should be calculated as the SHA3 (keccak-256) hash of the byte array formed as the concatenations of the second-leftmost 16 bytes of the derived key with the `ciphertext` key's contents, i.e.: +Once the file's key has been derived, it should be verified through the derivation of the MAC. The MAC should be calculated as the SHA3 (keccak-256) hash of the byte array formed as the concatenations of the second-leftmost 16 bytes of the derived key with the `ciphertext` key's contents, i.e.,: ```js KECCAK(DK[16..31] ++ ) @@ -66,7 +66,7 @@ This cipher takes the following parameters, given as keys to the cipherparams ke - `iv`: 128-bit initialisation vector for the cipher. -The key for the cipher is the leftmost 16 bytes of the derived key, i.e. `DK[0..15]` +The key for the cipher is the leftmost 16 bytes of the derived key, i.e., `DK[0..15]` The creation/encryption of a secret key should be essentially the reverse of these instructions. Make sure the `uuid`, `salt` and `iv` are actually random. From 6321040c642e0a9a08ee485d95f18c851b0ee164 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:35:12 -0500 Subject: [PATCH 025/212] hardstops on gas/index --- public/content/developers/docs/gas/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/docs/gas/index.md b/public/content/developers/docs/gas/index.md index 9c9356b96c0..92a1ac128d1 100644 --- a/public/content/developers/docs/gas/index.md +++ b/public/content/developers/docs/gas/index.md @@ -46,7 +46,7 @@ The total fee would now be equal to: where the `base fee` is a value set by the protocol and the `priority fee` is a value set by the user as a tip to the validator. -i.e. `21,000 * (10 + 2) = 252,000 gwei` (0.000252 ETH). +i.e., `21,000 * (10 + 2) = 252,000 gwei` (0.000252 ETH). When Jordan sends the money, 1.000252 ETH will be deducted from Jordan's account. Taylor will be credited 1.0000 ETH. The validator receives the tip of 0.000042 ETH. The `base fee` of 0.00021 ETH is burned. @@ -99,7 +99,7 @@ You can explicitly state how much you are willing to pay to get your transaction In short, gas fees help keep the Ethereum network secure. By requiring a fee for every computation executed on the network, we prevent bad actors from spamming the network. In order to avoid accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use. The fundamental unit of computation is "gas". -Although a transaction includes a limit, any gas not used in a transaction is returned to the user (i.e. `max fee - (base fee + tip)` is returned). +Although a transaction includes a limit, any gas not used in a transaction is returned to the user (i.e., `max fee - (base fee + tip)` is returned). ![Diagram showing how unused gas is refunded](../transactions/gas-tx.png) _Diagram adapted from [Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ From 13725315a834d1e6851a247c7e35fb6c1a257d06 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:36:22 -0500 Subject: [PATCH 026/212] hardstops on zero-knowledge-proofs/index --- public/content/zero-knowledge-proofs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/zero-knowledge-proofs/index.md b/public/content/zero-knowledge-proofs/index.md index c6bb6f15a8a..e71a5b592c7 100644 --- a/public/content/zero-knowledge-proofs/index.md +++ b/public/content/zero-knowledge-proofs/index.md @@ -32,7 +32,7 @@ Going back to our earlier example, the only evidence you need to prove your citi Credit card payments are often visible to multiple parties, including the payments provider, banks, and other interested parties (e.g., government authorities). While financial surveillance has benefits for identifying illegal activity, it also undermines the privacy of ordinary citizens. -Cryptocurrencies were intended to provide a means for users to conduct private, peer-to-peer transactions. But most cryptocurrency transactions are openly visible on public blockchains. User identities are often pseudonymous and either wilfully linked to real-world identities (e.g. by including ETH addresses on Twitter or GitHub profiles) or can be associated with real-world identities using basic on and offchain data analysis. +Cryptocurrencies were intended to provide a means for users to conduct private, peer-to-peer transactions. But most cryptocurrency transactions are openly visible on public blockchains. User identities are often pseudonymous and either wilfully linked to real-world identities (e.g., by including ETH addresses on Twitter or GitHub profiles) or can be associated with real-world identities using basic on and offchain data analysis. There are specific “privacy coins” designed for completely anonymous transactions. Privacy-focused blockchains, such as Zcash and Monero, shield transaction details, including sender/receiver addresses, asset type, quantity, and the transaction timeline. From 2585c4226fca8c5a4014bbda32ecc5fab7b8afcc Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:36:49 -0500 Subject: [PATCH 027/212] hardstops on merge/index --- public/content/translations/zh-tw/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/zh-tw/roadmap/merge/index.md b/public/content/translations/zh-tw/roadmap/merge/index.md index 563a1069ea7..7fbc7dfc984 100644 --- a/public/content/translations/zh-tw/roadmap/merge/index.md +++ b/public/content/translations/zh-tw/roadmap/merge/index.md @@ -118,7 +118,7 @@ id="developers"> +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> 以太坊的節點有兩種類型：可以提出區塊；無法提出區塊。 From 00baa2612af46ccf831575726a070ab1e73805cc Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:38:13 -0500 Subject: [PATCH 028/212] hardstops on languages/index --- .../zh-tw/developers/docs/smart-contracts/languages/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/zh-tw/developers/docs/smart-contracts/languages/index.md b/public/content/translations/zh-tw/developers/docs/smart-contracts/languages/index.md index 62b5200e430..dd01d7a1c0d 100644 --- a/public/content/translations/zh-tw/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/zh-tw/developers/docs/smart-contracts/languages/index.md @@ -177,7 +177,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) From f11a8e890d24321664bd144619598423fbdfb405 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:38:50 -0500 Subject: [PATCH 029/212] hardstops on merge/index --- public/content/translations/zh/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/zh/roadmap/merge/index.md b/public/content/translations/zh/roadmap/merge/index.md index 69d942972a1..e7fc3b6765c 100644 --- a/public/content/translations/zh/roadmap/merge/index.md +++ b/public/content/translations/zh/roadmap/merge/index.md @@ -118,7 +118,7 @@ id="developers"> +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> 以太坊节点有两种类型：可以提议区块的节点和不能提议区块的节点。 From 26cf37cf02e5b7732230b0223735f78088e86507 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:39:13 -0500 Subject: [PATCH 030/212] smart-contracts/languages/index --- .../zh/developers/docs/smart-contracts/languages/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/zh/developers/docs/smart-contracts/languages/index.md b/public/content/translations/zh/developers/docs/smart-contracts/languages/index.md index 5019302c164..02780dfe179 100644 --- a/public/content/translations/zh/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/zh/developers/docs/smart-contracts/languages/index.md @@ -174,7 +174,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) From 45f8ac4daa00744fec93a0a5c91b142d65c3c9d8 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:39:45 -0500 Subject: [PATCH 031/212] hardstops on roadmap/merge/index --- public/content/translations/uk/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/uk/roadmap/merge/index.md b/public/content/translations/uk/roadmap/merge/index.md index 3662c10117e..96c4291053a 100644 --- a/public/content/translations/uk/roadmap/merge/index.md +++ b/public/content/translations/uk/roadmap/merge/index.md @@ -118,7 +118,7 @@ id="developers"> +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Існує два типи вузлів Ethereum: вузли, які можуть пропонувати блоки, і вузли, які цього не можуть. From a367316cda6c08ee2adcfefc0fc18babe1eb3618 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:40:11 -0500 Subject: [PATCH 032/212] hardstops on roadmap/merge/index --- public/content/translations/tr/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/tr/roadmap/merge/index.md b/public/content/translations/tr/roadmap/merge/index.md index 9bd6faf8373..390f329ee4f 100644 --- a/public/content/translations/tr/roadmap/merge/index.md +++ b/public/content/translations/tr/roadmap/merge/index.md @@ -118,7 +118,7 @@ Birleşim aynı zamanda, iş ispatı altında mümkün olmayan daha fazla ölçe +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> İki tip Ethereum düğümü bulunur: Blok önerebilen ve öneremeyen düğümler. From ab1ad4b147279dfcb3b642287bb4a7259e4f2b12 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:40:38 -0500 Subject: [PATCH 033/212] hardstops on smart-contracts/languages/index --- .../tr/developers/docs/smart-contracts/languages/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/tr/developers/docs/smart-contracts/languages/index.md b/public/content/translations/tr/developers/docs/smart-contracts/languages/index.md index 28cb7a47c46..9c0ff09387d 100644 --- a/public/content/translations/tr/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/tr/developers/docs/smart-contracts/languages/index.md @@ -180,7 +180,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) From adaeb72121b046eee7caeb544b9ba24484841da0 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:41:00 -0500 Subject: [PATCH 034/212] hardstops on roadmap/merge/index --- public/content/translations/sl/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/sl/roadmap/merge/index.md b/public/content/translations/sl/roadmap/merge/index.md index e477ef01770..ca5109a4ee4 100644 --- a/public/content/translations/sl/roadmap/merge/index.md +++ b/public/content/translations/sl/roadmap/merge/index.md @@ -115,7 +115,7 @@ Spojitev je tudi postavila temelje za nadaljnje širitve omrežja, ki z dokazom +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Obstajata dve vrsti Ethereumovih vozlišč: vozlišča, ki predlagajo bloke, in vozlišča, ki jih ne. Vozlišča, ki predlagajo bloke, predstavljajo le majhno število vseh Ethereumovih vozlišč. Ta kategorija vključuje vozlišča za rudarjenje, ki uporabljajo mehanizem dokaza o delu, in validacijska vozlišča, ki uporabljajo mehanizem dokaza o deležu. Zahteva zagotavljanje ekonomskih virov (na primer računske moči grafične kartice za dokaz o delu ali zastavljenega ETH za dokaz o deležu) za možnost, da občasno predlagajo naslednji blok in zaslužijo nagrade, ki jih podeljuje protokol. From dec6603a3cf7bbf89bb60eb5cedd1efda29a2d45 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:41:29 -0500 Subject: [PATCH 035/212] hardstops on roadmap/merge/index --- public/content/translations/ru/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ru/roadmap/merge/index.md b/public/content/translations/ru/roadmap/merge/index.md index 6a3545f5ca5..4fcec3b12fe 100644 --- a/public/content/translations/ru/roadmap/merge/index.md +++ b/public/content/translations/ru/roadmap/merge/index.md @@ -118,7 +118,7 @@ id="developers"> +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Существует два типа узлов Ethereum: узлы, которые могут предлагать блоки, и те, которые не могут этого делать. From f7302211839ddb4899403c8a44aaa009b3fddadb Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:41:49 -0500 Subject: [PATCH 036/212] hardstops on roadmap/merge/index --- public/content/translations/ro/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ro/roadmap/merge/index.md b/public/content/translations/ro/roadmap/merge/index.md index f81e3778842..1917e041e98 100644 --- a/public/content/translations/ro/roadmap/merge/index.md +++ b/public/content/translations/ro/roadmap/merge/index.md @@ -111,7 +111,7 @@ De asemenea, Fuziunea a creat posibilitatea pentru și mai multe modernizări de +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Există două tipuri de noduri Ethereum: noduri care pot propune blocuri și noduri care nu pot propune blocuri. Nodurile care propun blocuri sunt doar un număr mic din numărul total de noduri pe Ethereum. Această categorie include noduri de minare în dovada muncii (PoW) și noduri de validator în dovada mizei (PoS). Această categorie necesită angajarea de resurse economice (precum puterea hashului pentru GPU în dovada muncii sau ETH mizat în dovada mizei) în schimbul posibilității de a propune ocazional următorul bloc și de a câștiga recompense acordate de protocol. From fa6d34ed0416689d05c4458806f7c45a23fcf6ad Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:42:38 -0500 Subject: [PATCH 037/212] hardstops on nft-minter/index --- .../ro/developers/tutorials/nft-minter/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/translations/ro/developers/tutorials/nft-minter/index.md b/public/content/translations/ro/developers/tutorials/nft-minter/index.md index 58a0e7ac729..54385707b5a 100644 --- a/public/content/translations/ro/developers/tutorials/nft-minter/index.md +++ b/public/content/translations/ro/developers/tutorials/nft-minter/index.md @@ -166,19 +166,19 @@ return (

🖼 Link to asset:

setURL(event.target.value)} />

🤔 Name:

setName(event.target.value)} />

✍️ Description:

setDescription(event.target.value)} /> @@ -448,7 +448,7 @@ function addWalletListener() { Let's quickly break down what's happening here: -- First, our function checks if `window.ethereum` is enabled \(i.e. MetaMask is installed\). +- First, our function checks if `window.ethereum` is enabled \(i.e., MetaMask is installed\). - If it's not, we simply set our `status` state variable to a JSX string that prompts the user to install MetaMask. - If it is enabled, we set up the listener `window.ethereum.on("accountsChanged")` on line 3 that listens for state changes in the MetaMask wallet, which include when the user connects an additional account to the dApp, switches accounts, or disconnects an account. If there is at least one account connected, the `walletAddress` state variable is updated as the first account in the `accounts` array returned by the listener. Otherwise, `walletAddress` is set as an empty string. From d9d4009dee02530f613ad1602c3291ba17249cec Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:43:05 -0500 Subject: [PATCH 038/212] hardstops on roadmap/merge/index --- public/content/translations/pt-br/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pt-br/roadmap/merge/index.md b/public/content/translations/pt-br/roadmap/merge/index.md index a8abeaad360..1428ecc96f1 100644 --- a/public/content/translations/pt-br/roadmap/merge/index.md +++ b/public/content/translations/pt-br/roadmap/merge/index.md @@ -118,7 +118,7 @@ The Merge também preparou o terreno para futuras atualizações de escalabilida +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Existem dois tipos de nós no Ethereum: nós que podem propor blocos e nós que não podem. From 77d47e69d455aa2c420c9b0f6407282d8e302349 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:43:54 -0500 Subject: [PATCH 039/212] hardstops on eip-1271-smart-contract-signatures/index --- .../tutorials/eip-1271-smart-contract-signatures/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pt-br/developers/tutorials/eip-1271-smart-contract-signatures/index.md b/public/content/translations/pt-br/developers/tutorials/eip-1271-smart-contract-signatures/index.md index 36a492a687b..fd950d155e5 100644 --- a/public/content/translations/pt-br/developers/tutorials/eip-1271-smart-contract-signatures/index.md +++ b/public/content/translations/pt-br/developers/tutorials/eip-1271-smart-contract-signatures/index.md @@ -98,7 +98,7 @@ No código do Safe, `isValidSignature` [ é implementada](https://github.com/saf 1. Mensagens on-chain 1. Criação: um proprietário Safe cria uma nova transação Safe para “assinar” a mensagem, passando a mensagem como um dado na transação. Uma vez que proprietários suficientes assinam a transação para alcançar o limite multisig, a transação é enviada e executada. Na transação, há uma função Safe chamada, que adiciona a mensagem à lista de mensagens “aprovadas”. - 2. Verificação: chame `isValidSignature` no contrato Safe, e transmita a mensagem para verificar enquanto parâmetro da mensagem e [ um parâmetro vazio como parâmetro da assinatura](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (i.e. `0x`). O Safe verá que o parâmetro da assinatura está vazio e, em vez de verificar a assinatura criptograficamente, ele saberá que deve prosseguir e verificar se a mensagem está na lista de mensagens “aprovadas”. + 2. Verificação: chame `isValidSignature` no contrato Safe, e transmita a mensagem para verificar enquanto parâmetro da mensagem e [ um parâmetro vazio como parâmetro da assinatura](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (i.e., `0x`). O Safe verá que o parâmetro da assinatura está vazio e, em vez de verificar a assinatura criptograficamente, ele saberá que deve prosseguir e verificar se a mensagem está na lista de mensagens “aprovadas”. 2. Mensagens off-chain: 1. Criação: um proprietário Safe cria uma mensagem off-chain, e então consegue outros proprietários Safe para assinar a mensagem, cada um individualmente, até que haja assinaturas suficientes para conseguir a aprovação pelo limite do multisig. 2. Verificação: chama `isValidSignature`. No parâmetro da mensagem, passa a mensagem para ser verificada. No parâmetro da assinatura, passa cada assinatura individual de proprietário Safe todas concatenadas juntas. O Safe irá checar que há assinaturas suficientes para atingir o limite **e** que cada assinatura é válida. Acontecendo isso, ele retornará um valor indicando verificação da assinatura com sucesso. From 8c9eca385e1d8d56edf6e1f1b733c9fa36293df2 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:44:21 -0500 Subject: [PATCH 040/212] hardstops on roadmap/merge/index --- public/content/translations/pl/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pl/roadmap/merge/index.md b/public/content/translations/pl/roadmap/merge/index.md index 1f9015d3330..7ec3d0131f5 100644 --- a/public/content/translations/pl/roadmap/merge/index.md +++ b/public/content/translations/pl/roadmap/merge/index.md @@ -118,7 +118,7 @@ Połączenie stwarza również miejsce dla dalszych uaktualnień skalowalności, +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Są dwa typy węzłów Ethereum: węzły, które mogą proponować bloki, i węzły, które tego nie mogą. From a343a0427dc8c0c526b923812cbf89d156c33239 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:44:49 -0500 Subject: [PATCH 041/212] hardstops on smart-contracts/languages/index --- .../pl/developers/docs/smart-contracts/languages/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pl/developers/docs/smart-contracts/languages/index.md b/public/content/translations/pl/developers/docs/smart-contracts/languages/index.md index ce2f7cd9621..c31aa87532e 100644 --- a/public/content/translations/pl/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/pl/developers/docs/smart-contracts/languages/index.md @@ -168,7 +168,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send Ether) + # with other contracts (i.e., they call functions or send Ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) From 8da5ada6eb90e453901b498db577543a1afc6452 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:45:39 -0500 Subject: [PATCH 042/212] hardstops on zero-knowledge-proofs/index --- public/content/translations/pcm/zero-knowledge-proofs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pcm/zero-knowledge-proofs/index.md b/public/content/translations/pcm/zero-knowledge-proofs/index.md index 7f3a96ebed7..6c987da7952 100644 --- a/public/content/translations/pcm/zero-knowledge-proofs/index.md +++ b/public/content/translations/pcm/zero-knowledge-proofs/index.md @@ -32,7 +32,7 @@ If wi go back to awa eksampol bifor, di only evidens yu nid to pruf yor citizens Kredit kard payments somtaims dey show plenti partis, wey inklude di payments provida, banks, and oda partis wey get intrest (e.g., gofament autoritis). As finanshial surveillans get gud side to sabi aktivity wey nor legit, im also look down on di privacy of ordinary citizens. -Cryptocurrencies suppose provide one means for users to do private, peer-to-peer transakshons. But plenti cryptocurrency transakshons dey show wella for publik blockchains. User identitis dey often bi fake and fit link to real-world identitis (e.g. by inkludin ETH address for Twitter abi GitHub profiles) abi fit join wit real-world identitis as yu dey yus basik on and off-chain data analysis. +Cryptocurrencies suppose provide one means for users to do private, peer-to-peer transakshons. But plenti cryptocurrency transakshons dey show wella for publik blockchains. User identitis dey often bi fake and fit link to real-world identitis (e.g., by inkludin ETH address for Twitter abi GitHub profiles) abi fit join wit real-world identitis as yu dey yus basik on and off-chain data analysis. Spesifik "privacy coins" dey wey dem disign for transakshons wey wi nor sabi kpatakpata. Blockchains wey fokus on privacy, laik Zcash and Monero, dey kova transakshon ditails, plus senda/risiva address, asset type, kwontity, and di transakshon taimline. From 03fbfc669411855acd64a3656d6650bd3e3cae19 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:46:04 -0500 Subject: [PATCH 043/212] hardstops on whitepaper/index --- public/content/translations/pcm/whitepaper/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pcm/whitepaper/index.md b/public/content/translations/pcm/whitepaper/index.md index f38b7064378..7036ea42a2a 100644 --- a/public/content/translations/pcm/whitepaper/index.md +++ b/public/content/translations/pcm/whitepaper/index.md @@ -78,7 +78,7 @@ Di first half of di first step dey privent pipol wey dey send transakshon from s ![Ethereum blocks](./ethereum-blocks.png) -If wi get access to one trustworthy sentralized savis, dis system go dey izy to run dis system; im fit simply dey koded exactly as dem diskribe am, as dem dey yus sentralized server hard drive to kip track of di state. But, wit Bitcoin wei dey try build disentralized kurensy system, so wi go nid kombine di state transakshon system wit di agreement system to make sure sey efribody agree on di order of transakshons. Bitcoin disentralized agreement process nid make nodes for di netwok dey always try make packajis of transakshons wey dem dey koll "blocks". Di netwok supose produs laik one block efri ten minutes, wit efri block make im dey get taimstamp, nonce, refrens to (i.e. hash of) di previous block and list of all di transakshons wey don hapun sinse di previous block. Ova taim, dis one go kreate pasistent, eva-growing, "blockchain" wey dey konstantly update to reprisent di latest state of di Bitcoin ledger. +If wi get access to one trustworthy sentralized savis, dis system go dey izy to run dis system; im fit simply dey koded exactly as dem diskribe am, as dem dey yus sentralized server hard drive to kip track of di state. But, wit Bitcoin wei dey try build disentralized kurensy system, so wi go nid kombine di state transakshon system wit di agreement system to make sure sey efribody agree on di order of transakshons. Bitcoin disentralized agreement process nid make nodes for di netwok dey always try make packajis of transakshons wey dem dey koll "blocks". Di netwok supose produs laik one block efri ten minutes, wit efri block make im dey get taimstamp, nonce, refrens to (i.e., hash of) di previous block and list of all di transakshons wey don hapun sinse di previous block. Ova taim, dis one go kreate pasistent, eva-growing, "blockchain" wey dey konstantly update to reprisent di latest state of di Bitcoin ledger. Di algorithm to dey sheck if one block dey valid, don ekpress in dis paradigm, na laik dis: From 64bbf21f6f7e6ba1d26d6e0ad3785e8fdc7ef943 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:46:36 -0500 Subject: [PATCH 044/212] hardstops on smart-contracts/index --- public/content/translations/pcm/smart-contracts/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pcm/smart-contracts/index.md b/public/content/translations/pcm/smart-contracts/index.md index f2f7b77f84d..d831c03921c 100644 --- a/public/content/translations/pcm/smart-contracts/index.md +++ b/public/content/translations/pcm/smart-contracts/index.md @@ -24,7 +24,7 @@ One eksampol dey hia: Alice and Bob wan do bicycle race. Make wi say Alice dey yus $10 wey e go yus win di race. Bob dey konfident sey e go win di race and agree to di bet. In di end, Alice dey finish di race well ahead of Bob and na di klear winna. But Bob rifuse to dey pay out on di bet, dey klaim sey Alice suppose don cheat. -Na dis kind silly eksampol we fit yus do ekampol for di palava wey nor smart. Even if dem don meet di kondishons (i.e. yu bi di winna of di race), yu suppose still trust anoda pesin to fulfill di agreement (i.e. payout on di bet). +Na dis kind silly eksampol we fit yus do ekampol for di palava wey nor smart. Even if dem don meet di kondishons (i.e., yu bi di winna of di race), yu suppose still trust anoda pesin to fulfill di agreement (i.e., payout on di bet). ## One digital vending machine {#vending-machine} From 1a5eeebbefb8953ca0e82c940f9c0ca1bf42ac9f Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:47:19 -0500 Subject: [PATCH 045/212] hardstops on smart-contracts/langauges/index --- .../pcm/developers/docs/smart-contracts/languages/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pcm/developers/docs/smart-contracts/languages/index.md b/public/content/translations/pcm/developers/docs/smart-contracts/languages/index.md index 17291150a11..f2a436d3076 100644 --- a/public/content/translations/pcm/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/pcm/developers/docs/smart-contracts/languages/index.md @@ -180,7 +180,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) From e90b5df6896c12786b15d4804f85dce99c0e6ad5 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:47:45 -0500 Subject: [PATCH 046/212] hardstops on smart-contracts/anatomy/index --- .../pcm/developers/docs/smart-contracts/anatomy/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/translations/pcm/developers/docs/smart-contracts/anatomy/index.md b/public/content/translations/pcm/developers/docs/smart-contracts/anatomy/index.md index 1b1d51a49c2..7677e23a9d8 100644 --- a/public/content/translations/pcm/developers/docs/smart-contracts/anatomy/index.md +++ b/public/content/translations/pcm/developers/docs/smart-contracts/anatomy/index.md @@ -76,9 +76,9 @@ To tok am for simpol tams, funshons fit get informashon abi set of informashon a Twi types of funshon kolls dey: - `internal` – dis ones nor dey kreate EVM koll - - Internal funshons and state variabols fit only hapun internaly (i.e. from inside di kurent kontract abi kontracts wey dey take from am) + - Internal funshons and state variabols fit only hapun internaly (i.e., from inside di kurent kontract abi kontracts wey dey take from am) - `external` – dis ones dey kreate EVM koll - - Ekstanal funshons nor dey part of di kontract interface, wey mean sey dem fit koll dem from oda kontracts and thru transakshons. Dem nor fit koll ekstanal funshon for inside `f` (i.e. `f()` nor dey work, but `dis one.f()` dey work). + - Ekstanal funshons nor dey part of di kontract interface, wey mean sey dem fit koll dem from oda kontracts and thru transakshons. Dem nor fit koll ekstanal funshon for inside `f` (i.e., `f()` nor dey work, but `dis one.f()` dey work). Dem fit also bi `publik` abi `private` From 5069d138a1269bff62b266e75c891d64836615c8 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:50:53 -0500 Subject: [PATCH 047/212] hardstops on roadmap/merge/index --- public/content/translations/nl/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/nl/roadmap/merge/index.md b/public/content/translations/nl/roadmap/merge/index.md index 43c38353766..17b7633d4fa 100644 --- a/public/content/translations/nl/roadmap/merge/index.md +++ b/public/content/translations/nl/roadmap/merge/index.md @@ -118,7 +118,7 @@ De samenvoeging heeft ook de weg vrijgemaakt voor verdere opschalingsupgrades di +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Er zijn twee soorten Ethereum-nodes: nodes die blocks kunnen voorstellen en nodes die dat niet kunnen. From 6db7b5a16cb532ccfba3ff34371966b1f40452dd Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:51:21 -0500 Subject: [PATCH 048/212] hardstops on smart-contracts/languages/index --- .../nl/developers/docs/smart-contracts/languages/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/nl/developers/docs/smart-contracts/languages/index.md b/public/content/translations/nl/developers/docs/smart-contracts/languages/index.md index 7aa8a5dcf52..6725c4fe7bd 100644 --- a/public/content/translations/nl/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/nl/developers/docs/smart-contracts/languages/index.md @@ -180,7 +180,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) From 0554e94e590888f32f3975055a575ed94b184d16 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:51:45 -0500 Subject: [PATCH 049/212] hardstops on roadmap/merge/index --- public/content/translations/ml/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ml/roadmap/merge/index.md b/public/content/translations/ml/roadmap/merge/index.md index f73cb4a726b..a82874f3980 100644 --- a/public/content/translations/ml/roadmap/merge/index.md +++ b/public/content/translations/ml/roadmap/merge/index.md @@ -115,7 +115,7 @@ id="developers"> +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> രണ്ട് തരം Ethereum നോഡുകൾ ഉണ്ട്: ബ്ലോക്കുകൾ നിർദ്ദേശിക്കാൻ കഴിയുന്ന നോഡുകളും അങ്ങനെയല്ലാത്ത നോഡുകളും. Ethereum-ലെ ആകെ നോഡുകളുടെ ഒരു ചെറിയ എണ്ണം മാത്രമാണ് ബ്ലോക്കുകൾ നിർദ്ദേശിക്കുന്ന നോഡുകൾ. ഈ വിഭാഗത്തിൽ പ്രൂഫ് ഓഫ് വർക്കിന് (PoW) കീഴിലുള്ള മൈനിംഗ് നോഡുകളും പ്രൂഫ് ഓഫ് സ്റ്റേക്കിന് (PoS) കീഴിലുള്ള വാലിഡേറ്റർ നോഡുകളും ഉൾപ്പെടുന്നു. ഈ വിഭാഗത്തിന് അടുത്ത ബ്ലോക്ക് ഇടയ്‌ക്കിടെ നിർദ്ദേശിക്കാനും പ്രോട്ടോക്കോൾ റിവാർഡുകൾ നേടാനുമുള്ള കഴിവിന് പകരമായി സാമ്പത്തിക റിസോഴ്‌സുകൾ (പ്രൂഫ് ഓഫ് വർക്കിൽ GPU ഹാഷ് പവർ അല്ലെങ്കിൽ പ്രൂഫ് ഓഫ് സ്റ്റേക്കിൽ സ്റ്റേക്ക്ഡ് ETH പോലുള്ളവ) ചുമതപ്പെടുത്തേണ്ടത് ആവശ്യമാണ്. From c43c789abd2d44544f834f18864ac4a7dd085bea Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:52:06 -0500 Subject: [PATCH 050/212] hardstops on roadmap/merge/index --- public/content/translations/ja/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ja/roadmap/merge/index.md b/public/content/translations/ja/roadmap/merge/index.md index efa8ed27240..f25dd78d669 100644 --- a/public/content/translations/ja/roadmap/merge/index.md +++ b/public/content/translations/ja/roadmap/merge/index.md @@ -118,7 +118,7 @@ id="developers"> +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> イーサリアムのノードには、ブロックを提案できるノードとできないノードがあります。 From 60a214a68b5f23554be49f27bb49abb6dd723d3c Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:52:39 -0500 Subject: [PATCH 051/212] hardstops on networking-layer/index --- public/content/developers/docs/networking-layer/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/docs/networking-layer/index.md b/public/content/developers/docs/networking-layer/index.md index e28914f0f26..4c50d8b1549 100644 --- a/public/content/developers/docs/networking-layer/index.md +++ b/public/content/developers/docs/networking-layer/index.md @@ -128,9 +128,9 @@ A summary of the control flow is shown below, with the relevant networking stack ### When consensus client is not block producer: {#when-consensus-client-is-not-block-producer} - Consensus client receives a block via the block gossip protocol (consensus p2p) -- Consensus client pre-validates the block, i.e. ensures it arrived from a valid sender with correct metadata +- Consensus client pre-validates the block, i.e., ensures it arrived from a valid sender with correct metadata - The transactions in the block are sent to the execution layer as an execution payload (local RPC connection) -- The execution layer executes the transactions and validates the state in the block header (i.e. checks hashes match) +- The execution layer executes the transactions and validates the state in the block header (i.e., checks hashes match) - Execution layer passes validation data back to consensus layer, block now considered to be validated (local RPC connection) - Consensus layer adds block to head of its own blockchain and attests to it, broadcasting the attestation over the network (consensus p2p) From 9cb35bea23422dc8892394674ab6e5dbca182382 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:53:03 -0500 Subject: [PATCH 052/212] hardstops on networks/index --- public/content/developers/docs/networks/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/networks/index.md b/public/content/developers/docs/networks/index.md index b6367551854..9e2b6463de5 100644 --- a/public/content/developers/docs/networks/index.md +++ b/public/content/developers/docs/networks/index.md @@ -182,7 +182,7 @@ A testnet for [Starknet](https://www.starknet.io). ## Private networks {#private-networks} -An Ethereum network is a private network if its nodes are not connected to a public network (i.e. Mainnet or a testnet). In this context, private only means reserved or isolated, rather than protected or secure. +An Ethereum network is a private network if its nodes are not connected to a public network (i.e., Mainnet or a testnet). In this context, private only means reserved or isolated, rather than protected or secure. ### Development networks {#development-networks} From a62d77f7541e3d6a3a5c7deaf8e79e8e014d6c48 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:53:49 -0500 Subject: [PATCH 053/212] hardstops on nodes-and-clients/index --- public/content/developers/docs/nodes-and-clients/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/developers/docs/nodes-and-clients/index.md b/public/content/developers/docs/nodes-and-clients/index.md index fe95fc21430..63a63be229d 100644 --- a/public/content/developers/docs/nodes-and-clients/index.md +++ b/public/content/developers/docs/nodes-and-clients/index.md @@ -57,7 +57,7 @@ If you want to [run your own node](/developers/docs/nodes-and-clients/run-a-node ### Full node {#full-node} -Full nodes do a block-by-block validation of the blockchain, including downloading and verifying the block body and state data for each block. There are different classes of full node - some start from the genesis block and verify every single block in the entire history of the blockchain. Others start their verification at a more recent block that they trust to be valid (e.g. Geth's 'snap sync'). Regardless of where the verification starts, full nodes only keep a local copy of relatively recent data (typically the most recent 128 blocks), allowing older data to be deleted to save disk space. Older data can be regenerated when it is needed. +Full nodes do a block-by-block validation of the blockchain, including downloading and verifying the block body and state data for each block. There are different classes of full node - some start from the genesis block and verify every single block in the entire history of the blockchain. Others start their verification at a more recent block that they trust to be valid (e.g., Geth's 'snap sync'). Regardless of where the verification starts, full nodes only keep a local copy of relatively recent data (typically the most recent 128 blocks), allowing older data to be deleted to save disk space. Older data can be regenerated when it is needed. - Stores full blockchain data (although this is periodically pruned so a full node does not store all state data back to genesis) - Participates in block validation, verifies all blocks and states. @@ -77,7 +77,7 @@ Learn more about [Archive nodes](/developers/docs/nodes-and-clients/archive-node ### Light node {#light-node} -Instead of downloading every block, light nodes only download block headers. These headers contain summary information about the contents of the blocks. Any other information the light node requires gets requested from a full node. The light node can then independently verify the data they receive against the state roots in the block headers. Light nodes enable users to participate in the Ethereum network without the powerful hardware or high bandwidth required to run full nodes. Eventually, light nodes might run on mobile phones or embedded devices. The light nodes do not participate in consensus (i.e. they cannot be validators), but they can access the Ethereum blockchain with the same functionality and security guarantees as a full node. +Instead of downloading every block, light nodes only download block headers. These headers contain summary information about the contents of the blocks. Any other information the light node requires gets requested from a full node. The light node can then independently verify the data they receive against the state roots in the block headers. Light nodes enable users to participate in the Ethereum network without the powerful hardware or high bandwidth required to run full nodes. Eventually, light nodes might run on mobile phones or embedded devices. The light nodes do not participate in consensus (i.e., they cannot be validators), but they can access the Ethereum blockchain with the same functionality and security guarantees as a full node. Light clients are an area of active development for Ethereum and we expect to see new light clients for the consensus layer and execution layer soon. There are also potential routes to providing light client data over the [gossip network](https://www.ethportal.net/). This is advantageous because the gossip network could support a network of light nodes without requiring full nodes to serve requests. @@ -96,7 +96,7 @@ Running your own node enables you to use Ethereum in a private, self-sufficient - You can use an Ethereum wallet with your own node. You can use dapps more securely and privately because you won't have to leak your addresses and balances to intermediaries. Everything can be checked with your own client. [MetaMask](https://metamask.io), [Frame](https://frame.sh/), and [many other wallets](/wallets/find-wallet/) offer RPC-importing, allowing them to use your node. - You can run and self-host other services which depend on data from Ethereum. For example, this might be a Beacon Chain validator, software like layer 2, infrastructure, block explorers, payment processors, etc. - You can provide your own custom [RPC endpoints](/developers/docs/apis/json-rpc/). You could even offer these endpoints publicly to the community to help them avoid big centralized providers. -- You can connect to your node using **Inter-process Communications (IPC)** or rewrite the node to load your program as a plugin. This grants low latency, which helps a lot, e.g. when processing a lot of data using web3 libraries or when you need to replace your transactions as fast as possible (i.e. frontrunning). +- You can connect to your node using **Inter-process Communications (IPC)** or rewrite the node to load your program as a plugin. This grants low latency, which helps a lot, e.g., when processing a lot of data using web3 libraries or when you need to replace your transactions as fast as possible (i.e., frontrunning). - You can directly stake ETH to secure the network and earn rewards. See [solo staking](/staking/solo/) to get started. ![How you access Ethereum via your application and nodes](./nodes.png) From d1fee5a5b47243cb458f112a36bd84588b2b8fa3 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:54:34 -0500 Subject: [PATCH 054/212] hardstops on oracles/index --- public/content/developers/docs/oracles/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/developers/docs/oracles/index.md b/public/content/developers/docs/oracles/index.md index 71ad6635d08..dd0941db94a 100644 --- a/public/content/developers/docs/oracles/index.md +++ b/public/content/developers/docs/oracles/index.md @@ -14,7 +14,7 @@ This page assumes the reader is familiar with Ethereum fundamentals, including [ ## What is a blockchain oracle? {#what-is-a-blockchain-oracle} -Oracles are applications that source, verify, and transmit external information (i.e. information stored offchain) to smart contracts running on the blockchain. Besides “pulling” offchain data and broadcasting it on Ethereum, oracles can also “push” information from the blockchain to external systems, e.g., unlocking a smart lock once the user sends a fee via an Ethereum transaction. +Oracles are applications that source, verify, and transmit external information (i.e., information stored offchain) to smart contracts running on the blockchain. Besides “pulling” offchain data and broadcasting it on Ethereum, oracles can also “push” information from the blockchain to external systems, e.g., unlocking a smart lock once the user sends a fee via an Ethereum transaction. Without an oracle, a smart contract would be limited entirely to onchain data. @@ -32,7 +32,7 @@ To achieve deterministic execution, blockchains limit nodes to reaching consensu - “Does this account have enough funds to cover the transaction?” - “Is this transaction valid in the context of this smart contract?”, etc. -If blockchains received information from external sources (i.e. from the real world), determinism would be impossible to achieve, preventing nodes from agreeing on the validity of changes to the blockchain’s state. Take for example a smart contract that executes a transaction based on the current ETH-USD exchange rate obtained from a traditional price API. This figure is likely to change frequently (not to mention that the API could get deprecated or hacked), meaning nodes executing the same contract code would arrive at different results. +If blockchains received information from external sources (i.e., from the real world), determinism would be impossible to achieve, preventing nodes from agreeing on the validity of changes to the blockchain’s state. Take for example a smart contract that executes a transaction based on the current ETH-USD exchange rate obtained from a traditional price API. This figure is likely to change frequently (not to mention that the API could get deprecated or hacked), meaning nodes executing the same contract code would arrive at different results. For a public blockchain like Ethereum, with thousands of nodes around the world processing transactions, determinism is critical. With no central authority serving as a source of truth, nodes need mechanisms for arriving at the same state after applying the same transactions. A case whereby node A executes a smart contract’s code and gets "3" as a result, while node B gets "7" after running the same transaction would cause consensus to break down and eliminate Ethereum’s value as a decentralized computing platform. @@ -44,7 +44,7 @@ Essentially, a blockchain oracle bridges the information gap between the blockch ## What is the oracle problem? {#the-oracle-problem} -Oracles solve an important problem, but also introduce some complications, e.g.: +Oracles solve an important problem, but also introduce some complications, e.g.,: - How do we verify that the injected information was extracted from the correct source or hasn’t been tampered with? @@ -54,7 +54,7 @@ The so-called “oracle problem” demonstrates the issues that come with using Different oracles offer different solutions to the oracle problem, which we explore later. Oracles are typically evaluated on how well they can handle the following challenges: -1. **Correctness**: An oracle should not cause smart contracts to trigger state changes based on invalid offchain data. An oracle must guarantee _authenticity_ and _integrity_ of data. Authenticity means the data was gotten from the correct source, while integrity means the data remained intact (i.e. wasn’t altered) before being sent onchain. +1. **Correctness**: An oracle should not cause smart contracts to trigger state changes based on invalid offchain data. An oracle must guarantee _authenticity_ and _integrity_ of data. Authenticity means the data was gotten from the correct source, while integrity means the data remained intact (i.e., wasn’t altered) before being sent onchain. 2. **Availability**: An oracle should not delay or prevent smart contracts from executing actions and triggering state changes. This means that data from an oracle must be _available on request_ without interruption. From f25782647a3aeeba174d4c3920dd9875235f9217 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 08:56:15 -0500 Subject: [PATCH 055/212] hardstops on scaling/plasma/index --- public/content/developers/docs/scaling/plasma/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/scaling/plasma/index.md b/public/content/developers/docs/scaling/plasma/index.md index a743e45ce89..e4489ace36b 100644 --- a/public/content/developers/docs/scaling/plasma/index.md +++ b/public/content/developers/docs/scaling/plasma/index.md @@ -72,7 +72,7 @@ If the challenge period elapses without anyone providing a fraud-proof, Alice's ### Dispute arbitration {#dispute-arbitration} -Like any blockchain, plasma chains need a mechanism for enforcing the integrity of transactions in case participants act maliciously (e.g. double-spending funds). To this end, plasma chains use fraud proofs to arbitrate disputes concerning the validity of state transitions and penalize bad behavior. Fraud proofs are used as a mechanism through which a Plasma child chain files a complaint to its parent chain or to the root chain. +Like any blockchain, plasma chains need a mechanism for enforcing the integrity of transactions in case participants act maliciously (e.g., double-spending funds). To this end, plasma chains use fraud proofs to arbitrate disputes concerning the validity of state transitions and penalize bad behavior. Fraud proofs are used as a mechanism through which a Plasma child chain files a complaint to its parent chain or to the root chain. A fraud-proof is simply a claim that a particular state transition is invalid. An example is if a user (Alice) tries to spend the same funds twice. Perhaps she spent the UTXO in a transaction with Bob and wants to spend the same UTXO (which is now Bob's) in another transaction. From 7248a804d31d16f50c087af00d2c0db85c5f6483 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:12:41 -0500 Subject: [PATCH 056/212] hardstops on smart-contracts/languages/index --- .../ja/developers/docs/smart-contracts/languages/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ja/developers/docs/smart-contracts/languages/index.md b/public/content/translations/ja/developers/docs/smart-contracts/languages/index.md index cbcf4351dab..63613fbf258 100644 --- a/public/content/translations/ja/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/ja/developers/docs/smart-contracts/languages/index.md @@ -180,7 +180,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) From 47db54ffdeb8aef7251e92f5a28154284546e4c1 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:12:55 -0500 Subject: [PATCH 057/212] hardstops on roadmap/merge/index --- public/content/translations/it/roadmap/merge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/it/roadmap/merge/index.md b/public/content/translations/it/roadmap/merge/index.md index 66700f86eb6..685d687167e 100644 --- a/public/content/translations/it/roadmap/merge/index.md +++ b/public/content/translations/it/roadmap/merge/index.md @@ -118,7 +118,7 @@ La Fusione ha inoltre gettato le basi per ulteriori aggiornamenti di scalabilit +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Esistono due tipi di nodi di Ethereum: i nodi che possono proporre blocchi e quelli che non possono. From 59f9051a94d2a5e299fe99787c9fc54707aa5499 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:14:38 -0500 Subject: [PATCH 058/212] hardstops on smart-contracts/languages/index --- .../cs/developers/docs/smart-contracts/languages/index.md | 2 +- .../fa/developers/docs/smart-contracts/languages/index.md | 2 +- .../fr/developers/docs/smart-contracts/languages/index.md | 2 +- .../ga/developers/docs/smart-contracts/languages/index.md | 2 +- .../hi/developers/docs/smart-contracts/languages/index.md | 2 +- .../hu/developers/docs/smart-contracts/languages/index.md | 2 +- .../it/developers/docs/smart-contracts/languages/index.md | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/public/content/translations/cs/developers/docs/smart-contracts/languages/index.md b/public/content/translations/cs/developers/docs/smart-contracts/languages/index.md index 882a65a5f1d..b9808c6028b 100644 --- a/public/content/translations/cs/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/cs/developers/docs/smart-contracts/languages/index.md @@ -180,7 +180,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) diff --git a/public/content/translations/fa/developers/docs/smart-contracts/languages/index.md b/public/content/translations/fa/developers/docs/smart-contracts/languages/index.md index cb5283f2962..0d4b2b65007 100644 --- a/public/content/translations/fa/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/fa/developers/docs/smart-contracts/languages/index.md @@ -180,7 +180,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) diff --git a/public/content/translations/fr/developers/docs/smart-contracts/languages/index.md b/public/content/translations/fr/developers/docs/smart-contracts/languages/index.md index d175c74a6c4..dd229c73706 100644 --- a/public/content/translations/fr/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/fr/developers/docs/smart-contracts/languages/index.md @@ -180,7 +180,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) diff --git a/public/content/translations/ga/developers/docs/smart-contracts/languages/index.md b/public/content/translations/ga/developers/docs/smart-contracts/languages/index.md index 93ace79f22c..7c40767cac0 100644 --- a/public/content/translations/ga/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/ga/developers/docs/smart-contracts/languages/index.md @@ -180,7 +180,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) diff --git a/public/content/translations/hi/developers/docs/smart-contracts/languages/index.md b/public/content/translations/hi/developers/docs/smart-contracts/languages/index.md index ac5398adf29..e6bdc22b3c1 100644 --- a/public/content/translations/hi/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/hi/developers/docs/smart-contracts/languages/index.md @@ -180,7 +180,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) diff --git a/public/content/translations/hu/developers/docs/smart-contracts/languages/index.md b/public/content/translations/hu/developers/docs/smart-contracts/languages/index.md index a2ab093066e..35bcb715141 100644 --- a/public/content/translations/hu/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/hu/developers/docs/smart-contracts/languages/index.md @@ -180,7 +180,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. feltételek ellenőrzése # 2. akció végrehajtás (potenciálisan megváltoztatja a feltételeket) diff --git a/public/content/translations/it/developers/docs/smart-contracts/languages/index.md b/public/content/translations/it/developers/docs/smart-contracts/languages/index.md index bb539e6c503..bd24ac56aa8 100644 --- a/public/content/translations/it/developers/docs/smart-contracts/languages/index.md +++ b/public/content/translations/it/developers/docs/smart-contracts/languages/index.md @@ -180,7 +180,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. controllo delle condizioni # 2. esecuzione delle azioni (potenzialmente modificando le condizioni) From 1801b172725d002e665541541954afb15824abdc Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:15:05 -0500 Subject: [PATCH 059/212] hard stops on smart-contracts/index --- public/content/smart-contracts/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/smart-contracts/index.md b/public/content/smart-contracts/index.md index ce04a3ee8b8..942c31c7759 100644 --- a/public/content/smart-contracts/index.md +++ b/public/content/smart-contracts/index.md @@ -29,7 +29,7 @@ Here is an example: Alice and Bob are having a bicycle race. Let's say Alice bets Bob $10 that she will win the race. Bob is confident he'll be the winner and agrees to the bet. In the end, Alice finishes the race well ahead of Bob and is the clear winner. But Bob refuses to pay out on the bet, claiming Alice must have cheated. -This silly example illustrates the problem with any non-smart agreement. Even if the conditions of the agreement get met (i.e. you are the winner of the race), you must still trust another person to fulfill the agreement (i.e. payout on the bet). +This silly example illustrates the problem with any non-smart agreement. Even if the conditions of the agreement get met (i.e., you are the winner of the race), you must still trust another person to fulfill the agreement (i.e., payout on the bet). ## A digital vending machine {#vending-machine} From f06edeb7ee4e557d140deb9e29cad393108f8b59 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:16:57 -0500 Subject: [PATCH 060/212] hard stops on roadmap/merge/index --- public/content/translations/ar/roadmap/merge/index.md | 2 +- public/content/translations/bg/roadmap/merge/index.md | 2 +- public/content/translations/cs/roadmap/merge/index.md | 2 +- public/content/translations/de/roadmap/merge/index.md | 2 +- public/content/translations/el/roadmap/merge/index.md | 2 +- public/content/translations/es/roadmap/merge/index.md | 2 +- public/content/translations/fa/roadmap/merge/index.md | 2 +- public/content/translations/fr/roadmap/merge/index.md | 2 +- public/content/translations/ga/roadmap/merge/index.md | 6 +++--- public/content/translations/hi/roadmap/merge/index.md | 2 +- public/content/translations/hr/roadmap/merge/index.md | 2 +- public/content/translations/hu/roadmap/merge/index.md | 2 +- public/content/translations/id/roadmap/merge/index.md | 2 +- 13 files changed, 15 insertions(+), 15 deletions(-) diff --git a/public/content/translations/ar/roadmap/merge/index.md b/public/content/translations/ar/roadmap/merge/index.md index e8a5806e3b7..4b2a88d4f87 100644 --- a/public/content/translations/ar/roadmap/merge/index.md +++ b/public/content/translations/ar/roadmap/merge/index.md @@ -115,7 +115,7 @@ id="developers"> +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> يوجد نوعان من عُقد إثيريوم: العُقد التي قد تقترح الكتل والعقد التي لا تقترح الكتل. حيث تمثل العُقد التي تقترح كتل فقط عددًا صغيرًا من مجموع العقد على إثيريوم. وتشمل هذه الفئة عُقد التنقيب بموجب إثبات العمل (PoW) وعقد برنامج المدقق بموجب إثبات الحصة (PoS). كما تتطلب هذه الفئة تخصيص مصادر اقتصادية (مثل قوة تجزئة GPU في إثبات العمل أو تجميد ETH في إثبات الحصة) نظير القدرة على اقتراح الكتلة التالية من حين لآخر والحصول على مكافآت البروتوكول. diff --git a/public/content/translations/bg/roadmap/merge/index.md b/public/content/translations/bg/roadmap/merge/index.md index aa04a025617..9766feb3112 100644 --- a/public/content/translations/bg/roadmap/merge/index.md +++ b/public/content/translations/bg/roadmap/merge/index.md @@ -115,7 +115,7 @@ id="developers"> +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Има два вида възли на Етереум: възли, които могат да предлагат блокове, и които не го правят. Възлите, които предлагат блокове, са само малък брой от всички възли в Етереум. Тази категория включва възли за добиване при доказателство-за-работа (PoW) и валидаторски възли при доказателство-за-залог (PoS). Тази категория изисква ангажиране с икономически ресурси (GPU хеш мощност при доказателство-за-работа или заложени ETH при доказателство-за-залог) в замяна на възможността периодично да предлагате следващия блок и да печелите награди за протоколи. diff --git a/public/content/translations/cs/roadmap/merge/index.md b/public/content/translations/cs/roadmap/merge/index.md index 95b038447bf..f30dba87882 100644 --- a/public/content/translations/cs/roadmap/merge/index.md +++ b/public/content/translations/cs/roadmap/merge/index.md @@ -118,7 +118,7 @@ Sloučení také připravilo půdu pro další škálovatelná vylepšení, kter +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Existují dva typy síťových uzlů Etherea: Uzly, které mohou navrhovat bloky, a uzly, které nemohou. diff --git a/public/content/translations/de/roadmap/merge/index.md b/public/content/translations/de/roadmap/merge/index.md index cba8f0ae4cf..23ff8845891 100644 --- a/public/content/translations/de/roadmap/merge/index.md +++ b/public/content/translations/de/roadmap/merge/index.md @@ -118,7 +118,7 @@ Die Zusammenführung ebnet auch den Weg für weitere Skalierungsupgrades, welche +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Es gibt zwei Arten von Ethereum Nodes: Nodes die Blöcke vorschlagen können und Nodes die das nicht können. diff --git a/public/content/translations/el/roadmap/merge/index.md b/public/content/translations/el/roadmap/merge/index.md index 175866b6bcb..23fb4afb9fc 100644 --- a/public/content/translations/el/roadmap/merge/index.md +++ b/public/content/translations/el/roadmap/merge/index.md @@ -118,7 +118,7 @@ id="developers"> +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Υπάρχουν δύο τύποι κόμβων Ethereum: οι κόμβοι που μπορούν να προτείνουν μπλοκ και οι κόμβοι που δεν μπορούν να προτείνουν. diff --git a/public/content/translations/es/roadmap/merge/index.md b/public/content/translations/es/roadmap/merge/index.md index ad5315318b4..a33e12490ce 100644 --- a/public/content/translations/es/roadmap/merge/index.md +++ b/public/content/translations/es/roadmap/merge/index.md @@ -118,7 +118,7 @@ La Fusión coloca a Ethereum en una nueva fase de actualizaciones escalables que +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Hay dos tipos de nodos en Ethereum: los que pueden proponer bloques y los que no. diff --git a/public/content/translations/fa/roadmap/merge/index.md b/public/content/translations/fa/roadmap/merge/index.md index 26d60c8705f..1c232fc1052 100644 --- a/public/content/translations/fa/roadmap/merge/index.md +++ b/public/content/translations/fa/roadmap/merge/index.md @@ -116,7 +116,7 @@ id="developers"> +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> دو نوع گره اتریوم وجود دارد: گره‌هایی که می‌توانند بلوک‌ها را پیشنهاد کنند و گره‌هایی که نمی‌توانند این کار را انجام دهند. diff --git a/public/content/translations/fr/roadmap/merge/index.md b/public/content/translations/fr/roadmap/merge/index.md index b500e2f32c2..7537853d1b7 100644 --- a/public/content/translations/fr/roadmap/merge/index.md +++ b/public/content/translations/fr/roadmap/merge/index.md @@ -118,7 +118,7 @@ La Fusion permet également de préparer le terrain pour d'autres améliorations +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Il existe deux types de nœuds sur Ethereum : ceux qui peuvent proposer de nouveaux blocs, et ceux qui ne le peuvent pas. diff --git a/public/content/translations/ga/roadmap/merge/index.md b/public/content/translations/ga/roadmap/merge/index.md index c77a9b3fbe4..30c00adb68c 100644 --- a/public/content/translations/ga/roadmap/merge/index.md +++ b/public/content/translations/ga/roadmap/merge/index.md @@ -118,13 +118,13 @@ Shocraigh an Cumasc freisin an chéim le haghaidh tuilleadh uasghrádaithe insc +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Tá dhá chineál nóid Ethereum ann: nóid ar féidir leo bloic a mholadh agus nóid nach molann. Níl na nóid a mholann bloic ach líon beag de na nóid iomlána ar Ethereum. Áirítear leis an gcatagóir seo nóid mhianadóireachta faoi chruthúnas oibre (PoW) agus nóid bhailíochtaithe faoi chruthúnas-gheallta (PoS). Éilíonn an chatagóir seo acmhainní eacnamaíocha a thiomnú (cosúil le cumhacht hash GPU mar chruthúnas oibre nó ETH geallta mar chruthúnas-gheallta) mar mhalairt ar an gcumas an chéad bhloc eile a mholadh ó am go chéile agus luach saothair prótacail a thuilleamh. -Ní cheanglaítear ar na nóid eile ar an líonra (i.e. an tromlach) aon acmhainní eacnamaíocha a thiomnú thar ríomhaire de ghrád tomhaltóra a bhfuil 1-2 TB de stóráil ar fáil agus nasc idirlín aige. Ní mholann na nóid seo bloic, ach tá ról ríthábhachtach acu fós chun an líonra a dhaingniú trí gach tairgeoir bloc a choinneáil cuntasach trí éisteacht le haghaidh bloic nua agus trína mbailíocht a fhíorú ar theacht dóibh de réir rialacha comhdhearcadh an líonra. Má tá an bloc bailí, leanann an nód ar aghaidh ag iomadú tríd an líonra. Má tá an bloc neamhbhailí ar chúis ar bith, déanfaidh na bogearraí nód neamhaird air mar neamhbhailí agus stopfaidh sé a iomadú. +Ní cheanglaítear ar na nóid eile ar an líonra (i.e., an tromlach) aon acmhainní eacnamaíocha a thiomnú thar ríomhaire de ghrád tomhaltóra a bhfuil 1-2 TB de stóráil ar fáil agus nasc idirlín aige. Ní mholann na nóid seo bloic, ach tá ról ríthábhachtach acu fós chun an líonra a dhaingniú trí gach tairgeoir bloc a choinneáil cuntasach trí éisteacht le haghaidh bloic nua agus trína mbailíocht a fhíorú ar theacht dóibh de réir rialacha comhdhearcadh an líonra. Má tá an bloc bailí, leanann an nód ar aghaidh ag iomadú tríd an líonra. Má tá an bloc neamhbhailí ar chúis ar bith, déanfaidh na bogearraí nód neamhaird air mar neamhbhailí agus stopfaidh sé a iomadú. Is féidir le duine ar bith faoi cheachtar meicníocht chomhthoil (cruthúnas oibre nó cruthúnas-gheallta) nód neamh-bhloctháirgthe a rith; seo rud a mholtar go láidir do gach úsáideoir má tá na hacmhainní acu. Tá sé thar a bheith luachmhar do Ethereum nód a rith agus tugann sé buntáistí breise d'aon duine a ritheann ceann, mar shlándáil fheabhsaithe, príobháideacht agus friotaíocht cinsireachta. @@ -149,7 +149,7 @@ title="Míthuiscint: "Cuireadh dlús suntasach le hidirbhearta mar gheall a contentPreview="False. Though some slight changes exist, transaction speed is mostly the same on layer 1 now as it was before The Merge."> Is féidir "luas" idirbhirt a thomhas ar chúpla bealach, lena n-áirítear am le cur san áireamh i mbloc agus am le tabhairt chun críche. Athraíonn an dá cheann seo beagán, ach ní ar bhealach a thabharfaidh úsáideoirí faoi deara. -Go stairiúil, ar chruthúnas oibre, ba é an sprioc a bhí ann bloc nua a bheith ann gach ~13.3 soicind. Faoi chruthúnas-gheallta, tarlaíonn sliotáin go beacht gach 12 soicind, agus tugann gach ceann díobh deis do bhailitheoir bloc a fhoilsiú. Bíonn bloic ag formhór na sliotán, ach ní gá go mbeadh bloc ag gach sliotán (i.e. tá bailíochtóir as líne). I gcás cruthúnais-gheallta, déantar bloic ~10% níos minice ná mar a dhéantar ar chruthúnas oibre. Ba athrú measartha neamhshuntasach é seo agus ní dócha go dtabharfaidh úsáideoirí faoi deara é. +Go stairiúil, ar chruthúnas oibre, ba é an sprioc a bhí ann bloc nua a bheith ann gach ~13.3 soicind. Faoi chruthúnas-gheallta, tarlaíonn sliotáin go beacht gach 12 soicind, agus tugann gach ceann díobh deis do bhailitheoir bloc a fhoilsiú. Bíonn bloic ag formhór na sliotán, ach ní gá go mbeadh bloc ag gach sliotán (i.e., tá bailíochtóir as líne). I gcás cruthúnais-gheallta, déantar bloic ~10% níos minice ná mar a dhéantar ar chruthúnas oibre. Ba athrú measartha neamhshuntasach é seo agus ní dócha go dtabharfaidh úsáideoirí faoi deara é. Thug cruthúnas-gheallta coincheap críochnaitheacht an idirbhirt nach raibh ann roimhe seo. Le linn cruthúnais oibre, éiríonn an cumas bloc a aisiompú thar a bheith níos deacra nuair a dhéantar gach bloc pasála a bhaintear de bhreis ar idirbheart, ach ní shroicheann sé nialas riamh. Faoi chruthúnas i gceist, déantar bloic a chuachadh ina dtréimhsí (réisí ama 6.4 nóiméad ina bhfuil 32 seans ar bhloic) a vótálann bailíochtaithe orthu. Nuair a thagann deireadh le ré, vótálann bailíochtaithe ar cheart an ré a mheas 'go bhfuil údar maith leis'. Má aontaíonn bailíochtaithe údar a thabhairt do ré, tabharfar chun críche é sa chéad tréimhse eile. Tá sé neamh-inmharthana go heacnamaíoch idirbhearta críochnaithe a chealú mar go mbeadh gá le breis agus trian den ETH iomlán atá i ngeall air a fháil agus a dhó. diff --git a/public/content/translations/hi/roadmap/merge/index.md b/public/content/translations/hi/roadmap/merge/index.md index 0bada75b184..143b2f484b8 100644 --- a/public/content/translations/hi/roadmap/merge/index.md +++ b/public/content/translations/hi/roadmap/merge/index.md @@ -118,7 +118,7 @@ id="developers"> +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> एथेरियम नोड्स दो प्रकार के होते हैं: नोड्स जो ब्लॉक को प्रस्ताव दे सकते हैं और ऐसे नोड्स जो नहीं देते हैं। diff --git a/public/content/translations/hr/roadmap/merge/index.md b/public/content/translations/hr/roadmap/merge/index.md index bbb0158606b..07a2f9ad6bb 100644 --- a/public/content/translations/hr/roadmap/merge/index.md +++ b/public/content/translations/hr/roadmap/merge/index.md @@ -115,7 +115,7 @@ Spajanje je postavilo temelje za nove nadogradnje skalabilnosti koje nisu bile m +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Postoje dvije vrste čvorova u Ethereumu: čvorovi koji mogu predložiti blokove i čvorovi koji to ne mogu. Čvorovi koji mogu predložiti blokove samo su mali dio cjelokupne količine blokova u Ethereumu. Ta kategorija uključuje čvorove za rudarenje po konceptu dokaza rada (proof-of-work – PoW) i čvorove validatora po konceptu dokaza uloga (proof-of-stake – PoS). Ta kategorija zahtijeva predaju ekonomskih resursa (kao GPU hash snaga u dokazu rada ili ulogi ETH-a u dokazu uloga) u zamjenu za mogućnost povremenih prijedloga sljedećeg bloka i zarade nagrada protokola. diff --git a/public/content/translations/hu/roadmap/merge/index.md b/public/content/translations/hu/roadmap/merge/index.md index 1be91ba7896..91adaae89ca 100644 --- a/public/content/translations/hu/roadmap/merge/index.md +++ b/public/content/translations/hu/roadmap/merge/index.md @@ -118,7 +118,7 @@ A beolvadás a további méretezhetőségi fejlesztések lehetőségét is megte +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Két típusú Ethereum-csomópont létezik: olyanok, amelyek képesek blokkjavaslatot tenni, és olyanok, amelyek nem. diff --git a/public/content/translations/id/roadmap/merge/index.md b/public/content/translations/id/roadmap/merge/index.md index 75c5e27af3c..61ac205f8bb 100644 --- a/public/content/translations/id/roadmap/merge/index.md +++ b/public/content/translations/id/roadmap/merge/index.md @@ -118,7 +118,7 @@ Penggabungan juga membuka jalan untuk peningkatan skalabilitas lebih lanjut yang +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> Ada dua jenis simpul Ethereum: simpul yang dapat mengusulkan blok dan simpul yang tidak. From b8370707eb8a177967c2bfc91abee912e4fd787f Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:17:14 -0500 Subject: [PATCH 061/212] hard stops on decentralized-identity/index --- public/content/translations/ga/decentralized-identity/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/decentralized-identity/index.md b/public/content/translations/ga/decentralized-identity/index.md index 300444cca8b..399e6d1b141 100644 --- a/public/content/translations/ga/decentralized-identity/index.md +++ b/public/content/translations/ga/decentralized-identity/index.md @@ -129,7 +129,7 @@ Seo scéal hipitéiseach chun fianuithe as slabhra a mhíniú: 1. Gineann ollscoil (an t-eisitheoir) fianú (teastas acadúil digiteach), síníonn sí é leis na heochracha, agus eisíonn sí é chuig Bob (úinéir na céannachta). -2. Déanann Bob iarratas ar phost agus ba mhaith leis a cháilíochtaí acadúla a chruthú le fostóir, mar sin roinneann sé an fianú óna sparán soghluaiste. Féadfaidh an chuideachta (an fíoraitheoir) bailíocht an fhianaithe a dhearbhú ansin trí DID an eisitheora a sheiceáil (i.e. a eochair phoiblí ar Ethereum). +2. Déanann Bob iarratas ar phost agus ba mhaith leis a cháilíochtaí acadúla a chruthú le fostóir, mar sin roinneann sé an fianú óna sparán soghluaiste. Féadfaidh an chuideachta (an fíoraitheoir) bailíocht an fhianaithe a dhearbhú ansin trí DID an eisitheora a sheiceáil (i.e., a eochair phoiblí ar Ethereum). ### Fianuithe as slabhra le rochtain leanúnach {#offchain-attestations-with-persistent-access} From b2cf96426d0855b63c87036c69770f169c00cd3e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:17:41 -0500 Subject: [PATCH 062/212] hard stops on nft-minter/index --- .../id/developers/tutorials/nft-minter/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/translations/id/developers/tutorials/nft-minter/index.md b/public/content/translations/id/developers/tutorials/nft-minter/index.md index 90fb21be116..c05abd6b673 100644 --- a/public/content/translations/id/developers/tutorials/nft-minter/index.md +++ b/public/content/translations/id/developers/tutorials/nft-minter/index.md @@ -164,19 +164,19 @@ return (

🖼 Link to asset:

setURL(event.target.value)} />

🤔 Name:

setName(event.target.value)} />

✍️ Description:

setDescription(event.target.value)} /> @@ -446,7 +446,7 @@ function addWalletListener() { Let's quickly break down what's happening here: -- First, our function checks if `window.ethereum` is enabled \(i.e. MetaMask is installed\). +- First, our function checks if `window.ethereum` is enabled \(i.e., MetaMask is installed\). - If it's not, we simply set our `status` state variable to a JSX string that prompts the user to install MetaMask. - If it is enabled, we set up the listener `window.ethereum.on("accountsChanged")` on line 3 that listens for state changes in the MetaMask wallet, which include when the user connects an additional account to the dApp, switches accounts, or disconnects an account. If there is at least one account connected, the `walletAddress` state variable is updated as the first account in the `accounts` array returned by the listener. Otherwise, `walletAddress` is set as an empty string. From 9d0806f782ba28960f87b8beec2fca6b577a7d2b Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:17:55 -0500 Subject: [PATCH 063/212] hard stops on whitepaper/index --- public/content/translations/ga/whitepaper/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/whitepaper/index.md b/public/content/translations/ga/whitepaper/index.md index 29eb932746c..267c837e249 100644 --- a/public/content/translations/ga/whitepaper/index.md +++ b/public/content/translations/ga/whitepaper/index.md @@ -315,7 +315,7 @@ Seo a leanas cur síos ginearálta ar conas DAO a chódú. Níl sa dearadh is si - `[1,i]` chun vóta a chlárú i bhfabhar thogra `i` - `[2,i]` chun an togra `i` a thabhairt chun críche má tá go leor vótaí déanta -Bheadh ​​clásail sa chonradh ansin do gach ceann díobh seo. Choimeádfadh sé taifead ar gach athrú stórais oscailte, mar aon le liosta de na daoine a vótáil ar a shon. Bheadh ​​liosta de na baill ar fad ann freisin. Nuair a vótálann dhá thrian de na comhaltaí ar son aon athrú stórais, d’fhéadfaí críochnú idirbhirt an t-athrú a dhéanamh. Bheadh ​​cumas vótála ionsuite ag creatlach níos sofaisticiúla freisin le haghaidh gnéithe cosúil le hidirbheart a sheoladh, baill a chur leis agus baill a bhaint, agus d'fhéadfadh sé fiú foráil a dhéanamh don [Daonlathas Leachtach ](https://wikipedia.org/wiki/Liquid_democracy)-stíl tharmligean vóta (i.e. is féidir le duine ar bith duine éigin a shannadh chun vótáil ar a son, agus tá an sannadh neamhbhuan mar sin má shannann A B agus smá shannann B C ansin cinneann C ceann A vóta). Cheadódh an dearadh seo don DAO fás go horgánach mar phobal díláraithe, rud a ligeann do dhaoine an tasc a bhaineann le scagadh amach cé atá ina bhall a tharmligean chuig speisialtóirí, cé, go murab ionann agus an "córas reatha", gur féidir le speisialtóirí teacht isteach agus amach go héasca le himeacht ama. de réir mar a athraíonn baill aonair pobail a gcuid ailínithe. +Bheadh ​​clásail sa chonradh ansin do gach ceann díobh seo. Choimeádfadh sé taifead ar gach athrú stórais oscailte, mar aon le liosta de na daoine a vótáil ar a shon. Bheadh ​​liosta de na baill ar fad ann freisin. Nuair a vótálann dhá thrian de na comhaltaí ar son aon athrú stórais, d’fhéadfaí críochnú idirbhirt an t-athrú a dhéanamh. Bheadh ​​cumas vótála ionsuite ag creatlach níos sofaisticiúla freisin le haghaidh gnéithe cosúil le hidirbheart a sheoladh, baill a chur leis agus baill a bhaint, agus d'fhéadfadh sé fiú foráil a dhéanamh don [Daonlathas Leachtach ](https://wikipedia.org/wiki/Liquid_democracy)-stíl tharmligean vóta (i.e., is féidir le duine ar bith duine éigin a shannadh chun vótáil ar a son, agus tá an sannadh neamhbhuan mar sin má shannann A B agus smá shannann B C ansin cinneann C ceann A vóta). Cheadódh an dearadh seo don DAO fás go horgánach mar phobal díláraithe, rud a ligeann do dhaoine an tasc a bhaineann le scagadh amach cé atá ina bhall a tharmligean chuig speisialtóirí, cé, go murab ionann agus an "córas reatha", gur féidir le speisialtóirí teacht isteach agus amach go héasca le himeacht ama. de réir mar a athraíonn baill aonair pobail a gcuid ailínithe. Is samhail mhalartach é do chorparáid dhíláraithe, nuair is féidir le nialas nó níos mó scaireanna a bheith ag aon chuntas, agus éilítear dhá thrian de na scaireanna chun cinneadh a dhéanamh. Bheadh ​​feidhmiúlacht bainistíochta sócmhainní i gceist le creatlach iomlán, an cumas chun tairiscint a dhéanamh chun scaireanna a cheannach nó a dhíol, agus an cumas glacadh le tairiscintí (b’fhearr le meicníocht ordaithe laistigh den chonradh). Bheadh ​​an tarmligean ann freisin ar nós an Daonlathais Leachtaigh, rud a dhéanfadh ginearálú ar choincheap “bord stiúrthóirí”. From 20371c991a4c531fe8a13630af7adfc588aa7866 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:18:08 -0500 Subject: [PATCH 064/212] hard stops on smart-contracts/index --- public/content/translations/ga/smart-contracts/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/smart-contracts/index.md b/public/content/translations/ga/smart-contracts/index.md index 53df541fa8c..a3c5fc78aba 100644 --- a/public/content/translations/ga/smart-contracts/index.md +++ b/public/content/translations/ga/smart-contracts/index.md @@ -29,7 +29,7 @@ Seo sampla: Tá rás rothar ar siúl ag Alice agus Bob. Deirimis go ngeallann Alice $10 do Bob go mbeidh an bua aici sa rás. Tá Bob muiníneach gurb é féin a bheidh mar bhuaiteoir agus aontaíonn sé leis an ngeall. Sa deireadh, críochnaíonn Alice an rás go maith chun tosaigh ar Bob agus níl aon amhras ach gurb ise an buaiteoir. Ach diúltaíonn Bob a íoc as an ngeall, agus deir sé go ndearna Alice caimiléireacht air. -Léiríonn an sampla amaideach seo an fhadhb le haon chomhaontú neamhchliste. Fiú má shásaítear coinníollacha an chomhaontaithe (i.e. is tusa buaiteoir an rása), ní mór duit muinín a bheith agat as duine eile fós chun an comhaontú a chomhlíonadh (i.e. íocaíocht a dhéanamh ar an ngeall). +Léiríonn an sampla amaideach seo an fhadhb le haon chomhaontú neamhchliste. Fiú má shásaítear coinníollacha an chomhaontaithe (i.e., is tusa buaiteoir an rása), ní mór duit muinín a bheith agat as duine eile fós chun an comhaontú a chomhlíonadh (i.e., íocaíocht a dhéanamh ar an ngeall). ## Meaisín díola digiteach {#vending-machine} From ee7fb8da277026a2748fcf93e23eb571deab09ca Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:18:24 -0500 Subject: [PATCH 065/212] hardstops on single-slot-finality/index --- .../translations/ga/roadmap/single-slot-finality/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/translations/ga/roadmap/single-slot-finality/index.md b/public/content/translations/ga/roadmap/single-slot-finality/index.md index 75373dfff34..a9339628a76 100644 --- a/public/content/translations/ga/roadmap/single-slot-finality/index.md +++ b/public/content/translations/ga/roadmap/single-slot-finality/index.md @@ -46,7 +46,7 @@ Sa scéim seo, ní féidir le gach bailíochtóir vóta a chaitheamh ar bhloc ac D’fhéadfaí tuilleadh gnóthachain éifeachtachta a bhaint amach trí shárchoistí a chruthú de m.sh. 125,000 bailíochtóir roghnaithe go randamach in aghaidh na sliotán. Ní fhaigheann ach na bailíochtóirí sin vóta ar bhloc agus mar sin ní chinneann ach an fo-thacar seo de bhailíochtóirí an dtabharfar bloc go críochnaitheacht. Cé acu an smaoineamh maith é seo nó nach ea, braitheann sé ar cé chomh costasach is fearr leis an bpobal ionsaí rathúil ar Ethereum a bheith. Tá sé seo amhlaidh toisc go bhféadfadh ionsaitheoir bloc mímhacánta a thabhairt go críochnaitheacht ina mbeadh 2/3 den éitear cruachta _san sárchoiste sin_ in ionad 2/3 den éitear iomlán a bheith ag teastáil. Is réimse gníomhach taighde é seo go fóill, ach tá dealramh leis go mbeidh costas an-ard ar ionsaí ar cheann de na fochoistí sin i gcás tacar bailíochtaithe atá sách mór chun go mbeadh ollchoistí uathu (m.sh. bheadh ​​costas an ionsaí ainmnithe ag ETH. `2/3 * 125,000 * 32 = ~2.6 milliún ETH`). Is féidir costas an ionsaithe a choigeartú trí mhéid an tacair bhailíochtóra a mhéadú (m.sh. méid an bhailíochtóra a oiriúnú ionas go mbeidh costas an ionsaithe comhionann le 1 milliún éitear, 4 mhilliún éitear, 10 milliún éitear, srl). Is cosúil go dtugann [Réamh pobalbhreith](https://youtu.be/ojBgyFl6-v4?t=755) an phobail le fios gur costas inghlactha ionsaí é 1-2 mhilliún éitear, rud a chiallaíonn ~ 65,536 - 97,152 bailíochtóir in aghaidh an ollchoiste. -Mar sin féin, ní hé an fíorú an bac fíor - is é an comhiomlánú sínithe an dúshlán is mó do na nóid bhailíochtóirí. Chun comhiomlánú sínithe a scálú is dócha go mbeidh gá le méadú ar líon na bhailitheoirí i ngach folíonra, ag méadú líon na bhfo-líonraí, nó ag cur sraitheanna breise comhiomlánaithe (i.e. coistí coistí forfheidhmithe). D'fhéadfadh go gceadódh cuid den réiteach comhbhailitheoirí speisialaithe - cosúil leis an gcaoi a ndéanfar blocthógáil agus tiomantais a ghiniúint le haghaidh sonraí rollta suas a fhoinsiú allamuigh chuig tógálaithe bloc speisialaithe faoi scaradh moltóir-tógálaí (PBS) agus Danksharding. +Mar sin féin, ní hé an fíorú an bac fíor - is é an comhiomlánú sínithe an dúshlán is mó do na nóid bhailíochtóirí. Chun comhiomlánú sínithe a scálú is dócha go mbeidh gá le méadú ar líon na bhailitheoirí i ngach folíonra, ag méadú líon na bhfo-líonraí, nó ag cur sraitheanna breise comhiomlánaithe (i.e., coistí coistí forfheidhmithe). D'fhéadfadh go gceadódh cuid den réiteach comhbhailitheoirí speisialaithe - cosúil leis an gcaoi a ndéanfar blocthógáil agus tiomantais a ghiniúint le haghaidh sonraí rollta suas a fhoinsiú allamuigh chuig tógálaithe bloc speisialaithe faoi scaradh moltóir-tógálaí (PBS) agus Danksharding. ## Cén ról atá ag an riail forc-rogha san SSF? {#role-of-the-fork-choice-rule} @@ -54,7 +54,7 @@ Tá an meicníocht chomhoiriúnachta atá ann inniu ag brath ar nasc dlúth idir ## Saincheisteanna gan réiteach {#outstanding-issues} -Is í an fhadhb a bhaineann le comhiomlánú scálaithe trí líon na mbailíochtórí in aghaidh an fho-líonra a mhéadú ná go mbíonn ualach níos mó ar an líonra piara le piara mar thoradh air. Is í an fhadhb a bhaineann le sraitheanna comhiomlána a chur leis ná go mbaineann innealtóireacht measartha casta leis agus go gcuireann sé aga folaigh leis (i.e. d’fhéadfadh níos mó ama a bheith de dhíth ar an mholtóir an bhloic cloisteáil ó na comhbhailitheoirí folíonra go léir). Níl sé soiléir freisin conas déileáil leis an gcás go bhfuil níos mó bailíochtóirí gníomhacha ar an líonra ná mar is féidir a phróiseáil i ngach sliotán, fiú le comhiomlánú sínithe BLS. Réiteach amháin is ea, toisc go mbíonn gach bailíochtóir ag fianú i ngach sliotán agus nach bhfuil aon choistí faoi SSF, go bhféadfaí an teorainn 32 ETH ar an gcothromaíocht éifeachtach a bhaint go hiomlán, agus bheadh oibreoirí a bhainistíonn bailíochtóiirí iolracha a ngeall a chomhdhlúthú agus níos lú a reáchtáil, rud a laghdódh an líon teachtaireachtaí a bhíonn le proiseáil ag nóid bhailíochtaithe chun cuntas a thabhairt ar an tacar bailíochtaithe ar fad. Braitheann sé seo ar chomhaontú a bheith idir geallsealbhóírí móra a gcuid bailíochtaithe a chomhdhlúthú. Is féidir freisin teorainn sheasta a fhorchur ar líon na mbailíochtóirí nó ar an méid ETH atá i gceist tráth ar bith. Éilíonn sé seo meicníocht éigin le cinneadh cé na bailíochtóirí a cheadaítear a bheith rannpháirteach agus cé nach bhfuil, áfach, agus d'fhéadfaí éifeachtaí tánaisteacha nach dteastaíonn a chruthú dá bharr. +Is í an fhadhb a bhaineann le comhiomlánú scálaithe trí líon na mbailíochtórí in aghaidh an fho-líonra a mhéadú ná go mbíonn ualach níos mó ar an líonra piara le piara mar thoradh air. Is í an fhadhb a bhaineann le sraitheanna comhiomlána a chur leis ná go mbaineann innealtóireacht measartha casta leis agus go gcuireann sé aga folaigh leis (i.e., d’fhéadfadh níos mó ama a bheith de dhíth ar an mholtóir an bhloic cloisteáil ó na comhbhailitheoirí folíonra go léir). Níl sé soiléir freisin conas déileáil leis an gcás go bhfuil níos mó bailíochtóirí gníomhacha ar an líonra ná mar is féidir a phróiseáil i ngach sliotán, fiú le comhiomlánú sínithe BLS. Réiteach amháin is ea, toisc go mbíonn gach bailíochtóir ag fianú i ngach sliotán agus nach bhfuil aon choistí faoi SSF, go bhféadfaí an teorainn 32 ETH ar an gcothromaíocht éifeachtach a bhaint go hiomlán, agus bheadh oibreoirí a bhainistíonn bailíochtóiirí iolracha a ngeall a chomhdhlúthú agus níos lú a reáchtáil, rud a laghdódh an líon teachtaireachtaí a bhíonn le proiseáil ag nóid bhailíochtaithe chun cuntas a thabhairt ar an tacar bailíochtaithe ar fad. Braitheann sé seo ar chomhaontú a bheith idir geallsealbhóírí móra a gcuid bailíochtaithe a chomhdhlúthú. Is féidir freisin teorainn sheasta a fhorchur ar líon na mbailíochtóirí nó ar an méid ETH atá i gceist tráth ar bith. Éilíonn sé seo meicníocht éigin le cinneadh cé na bailíochtóirí a cheadaítear a bheith rannpháirteach agus cé nach bhfuil, áfach, agus d'fhéadfaí éifeachtaí tánaisteacha nach dteastaíonn a chruthú dá bharr. ## Dul chun cinn reatha {#current-progress} From 1368dbe6d656d458749fdd4a83b74f2f01d75730 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:18:37 -0500 Subject: [PATCH 066/212] hardstops on mege/issuance/index --- public/content/translations/ga/roadmap/merge/issuance/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/roadmap/merge/issuance/index.md b/public/content/translations/ga/roadmap/merge/issuance/index.md index 1c270f12025..107c88233cb 100644 --- a/public/content/translations/ga/roadmap/merge/issuance/index.md +++ b/public/content/translations/ga/roadmap/merge/issuance/index.md @@ -6,7 +6,7 @@ lang: ga # Conas a chuaigh an Cumasc i bhfeidhm ar sholáthar ETH {#how-the-merge-impacts-ETH-supply} -Ba ionann an Cumasc agus aistriú líonra Ethereum ó chruthúnas oibre go cruthúnas-gheallta a tharla i Meán Fómhair 2022. Rinneadh athruithe ar an mbealach ar eisíodh ETH tráth an aistrithe sin. Roimhe seo, eisíodh ETH nua ó dhá fhoinse: an ciseal forghníomhaithe (i.e. Mainnet) agus an ciseal comhthola (i.e. Slabhra Beacon). Ó tharla an Cumasc, tá eisiúint ar an gciseal fhorghníomhú anois náid. Déanaimis é seo a bhriseadh síos. +Ba ionann an Cumasc agus aistriú líonra Ethereum ó chruthúnas oibre go cruthúnas-gheallta a tharla i Meán Fómhair 2022. Rinneadh athruithe ar an mbealach ar eisíodh ETH tráth an aistrithe sin. Roimhe seo, eisíodh ETH nua ó dhá fhoinse: an ciseal forghníomhaithe (i.e., Mainnet) agus an ciseal comhthola (i.e., Slabhra Beacon). Ó tharla an Cumasc, tá eisiúint ar an gciseal fhorghníomhú anois náid. Déanaimis é seo a bhriseadh síos. ## Comhpháirteanna eisiúint ETH {#components-of-eth-issuance} From c4ef1bd5446f89736e1e11d2cbe64d1a3a550f45 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:18:58 -0500 Subject: [PATCH 067/212] hard stops on how-to-create-an-ethereum-account/index --- .../translations/ga/how-to-create-an-ethereum-account/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/how-to-create-an-ethereum-account/index.md b/public/content/translations/ga/how-to-create-an-ethereum-account/index.md index 69b569835a9..e4a64e989b6 100644 --- a/public/content/translations/ga/how-to-create-an-ethereum-account/index.md +++ b/public/content/translations/ga/how-to-create-an-ethereum-account/index.md @@ -58,7 +58,7 @@ Ní féidir. Is uirlis bhainistíochta é an sparán a chuidíonn leat cuntais a ### An féidir liom bitcoin a sheoladh chuig seoladh Ethereum, nó éitear chuig seoladh Bitcoin? -Ní féidir leat. Tá Bitcoin agus éitear ar dhá líonra ar leith (i.e. blocshlabhraí éagsúla), agus a bhformáidí leabharchoimeád agus tá a seoltaí féin ag gach ceann acu. Rinneadh iarrachtaí éagsúla an dá líonra difriúla a dhúnadh, agus is é an ceann is gníomhaí faoi láthair ná [Wrapped Bitcoin nó WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/). Ní moladh é seo, toisc gur réiteach coimeádta é WBTC (a chiallaíonn go rialaíonn grúpa amháin daoine feidhmeanna ríthábhachtacha áirithe) agus cuirtear ar fáil anseo é chun críocha faisnéise amháin. +Ní féidir leat. Tá Bitcoin agus éitear ar dhá líonra ar leith (i.e., blocshlabhraí éagsúla), agus a bhformáidí leabharchoimeád agus tá a seoltaí féin ag gach ceann acu. Rinneadh iarrachtaí éagsúla an dá líonra difriúla a dhúnadh, agus is é an ceann is gníomhaí faoi láthair ná [Wrapped Bitcoin nó WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/). Ní moladh é seo, toisc gur réiteach coimeádta é WBTC (a chiallaíonn go rialaíonn grúpa amháin daoine feidhmeanna ríthábhachtacha áirithe) agus cuirtear ar fáil anseo é chun críocha faisnéise amháin. ### Má tá seoladh ETH agam, an liomsa an seoladh céanna ar bhlocshlabhraí eile? From 360b1e15e8e01376d3aee95646622afd38dcc12b Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:19:21 -0500 Subject: [PATCH 068/212] hard stops on how-to-create-an-ethereum-account/index --- .../ga/guides/how-to-create-an-ethereum-account/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/guides/how-to-create-an-ethereum-account/index.md b/public/content/translations/ga/guides/how-to-create-an-ethereum-account/index.md index 9eeae716a7d..91260840a9d 100644 --- a/public/content/translations/ga/guides/how-to-create-an-ethereum-account/index.md +++ b/public/content/translations/ga/guides/how-to-create-an-ethereum-account/index.md @@ -58,7 +58,7 @@ Ní féidir. Is uirlis bhainistíochta é an sparán a chuidíonn leat cuntais a ### An féidir liom bitcoin a sheoladh chuig seoladh Ethereum, nó éitear chuig seoladh Bitcoin? -Ní féidir leat. Tá Bitcoin agus éitear ar dhá líonra ar leith (i.e. blocshlabhraí éagsúla), agus a bhformáidí leabharchoimeád agus tá a seoltaí féin ag gach ceann acu. Rinneadh iarrachtaí éagsúla an dá líonra difriúla a dhúnadh, agus is é an ceann is gníomhaí faoi láthair ná [Wrapped Bitcoin nó WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/). Ní moladh é seo, toisc gur réiteach coimeádta é WBTC (a chiallaíonn go rialaíonn grúpa amháin daoine feidhmeanna ríthábhachtacha áirithe) agus cuirtear ar fáil anseo é chun críocha faisnéise amháin. +Ní féidir leat. Tá Bitcoin agus éitear ar dhá líonra ar leith (i.e., blocshlabhraí éagsúla), agus a bhformáidí leabharchoimeád agus tá a seoltaí féin ag gach ceann acu. Rinneadh iarrachtaí éagsúla an dá líonra difriúla a dhúnadh, agus is é an ceann is gníomhaí faoi láthair ná [Wrapped Bitcoin nó WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/). Ní moladh é seo, toisc gur réiteach coimeádta é WBTC (a chiallaíonn go rialaíonn grúpa amháin daoine feidhmeanna ríthábhachtacha áirithe) agus cuirtear ar fáil anseo é chun críocha faisnéise amháin. ### Má tá seoladh ETH agam, an liomsa an seoladh céanna ar bhlocshlabhraí eile? From b7fd536a493401c93a63144f9872c4a29fca861d Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:19:36 -0500 Subject: [PATCH 069/212] hard stops on transactions/index --- .../translations/ga/developers/docs/transactions/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/developers/docs/transactions/index.md b/public/content/translations/ga/developers/docs/transactions/index.md index 4fb1bdbb4c9..fda8e5e04d9 100644 --- a/public/content/translations/ga/developers/docs/transactions/index.md +++ b/public/content/translations/ga/developers/docs/transactions/index.md @@ -164,7 +164,7 @@ Tá gás riachtanach le haghaidh aon idirbheart a bhaineann le conradh cliste. Féadfaidh feidhmeanna ar a dtugtar [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) nó `pure` feidhmeanna, nach n-athraíonn staid an chonartha. Mar sin, ní bheidh gá le haon ghás chun na feidhmeanna seo a ghlaoch ó EOA. Is é an glao RPC bunúsach don chás seo ná [`eth_call`](/developers/docs/apis/json-rpc#eth_call). -Murab ionann agus nuair a dhéantar rochtain orthu trí úsáid a bhaint as `eth_call`, is gnách go dtugtar go hinmheánach ar na feidhmeanna `view` nó `pure` seo (i.e. ón gconradh féin nó ó chonradh eile) a dhéanann costas gáis. +Murab ionann agus nuair a dhéantar rochtain orthu trí úsáid a bhaint as `eth_call`, is gnách go dtugtar go hinmheánach ar na feidhmeanna `view` nó `pure` seo (i.e., ón gconradh féin nó ó chonradh eile) a dhéanann costas gáis. ## Saolré idirbhirt {#transaction-lifecycle} From 90ecef3a3e4f825f595cfb491d06d35869b0ce6e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:19:47 -0500 Subject: [PATCH 070/212] hard stops on bridges/index --- public/content/translations/ga/developers/docs/bridges/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/developers/docs/bridges/index.md b/public/content/translations/ga/developers/docs/bridges/index.md index 87b65cd6b00..7ddbdb89ed2 100644 --- a/public/content/translations/ga/developers/docs/bridges/index.md +++ b/public/content/translations/ga/developers/docs/bridges/index.md @@ -51,7 +51,7 @@ Le droichid, níl aon réitigh foirfe ann. Ina ionad sin, ní dhéantar ach comh - **Slándáil –** Cé a fhíoraíonn an córas? De ghnáth ní bhíonn na droichid atá daingnithe ag bailíochtaithe seachtracha chomh slán ná na droichid atá daingnithe go háitiúil nó ó dhúchas ag bailíochtóirí na blocshlabhra. - **Áisiúlacht –** Cé chomh fada a thógann sé idirbheart a chur i gcrích, agus cé mhéad idirbheart a bhí ar úsáideoir a shíniú? Maidir le forbróir, cé chomh fada agus a thógann sé droichead a chomhtháthú, agus cé chomh casta atá an próiseas? -- ** Nascacht –** Cad iad na slabhraí cinn scríbe éagsúla is féidir le droichead a nascadh (i.e. rolladh suas, slabhraí taoibh, blocshlabhraí ciseal 1 eile, etc.), agus cé chomh deacair is atá sé blocshlabhra nua a chomhtháthú? +- ** Nascacht –** Cad iad na slabhraí cinn scríbe éagsúla is féidir le droichead a nascadh (i.e., rolladh suas, slabhraí taoibh, blocshlabhraí ciseal 1 eile, etc.), agus cé chomh deacair is atá sé blocshlabhra nua a chomhtháthú? - **In ann sonraí níos casta a rith –** An féidir le droichead aistriú teachtaireachtaí agus sonraí treallacha níos casta thar slabhraí a chumasú, nó an dtacaíonn sé le haistrithe sócmhainní tras-slabhra amháin? - **Éifeachtacht costais –** Cé mhéad a chosnaíonn sé sócmhainní a aistriú thar slabhraí trí dhroichead? Go hiondúil, gearrann droichid táille sheasta nó athraitheach ag brath ar chostais gháis agus leachtacht bealaí sonracha. Tá sé ríthábhachtach freisin costas-éifeachtacht droichid a mheas bunaithe ar an gcaipiteal a theastaíonn chun a shlándáil a chinntiú. From faa8e7f06628f37808c6184cdebc18fe6e35ffe9 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:20:02 -0500 Subject: [PATCH 071/212] hard stops on consensus-mechanism/pow/index --- .../ga/developers/docs/consensus-mechanisms/pow/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/index.md index d9b0900bdc9..c61aa1cc537 100644 --- a/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/index.md +++ b/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/index.md @@ -16,7 +16,7 @@ Chun an leathanach seo a thuiscint níos fearr, molaimid duit léamh ar [idirbhe ## Cad é Cruthúnas-oibre (PoW)? {#what-is-pow} -Is é comhdhearcadh Nakamoto, a úsáideann cruthúnas-oibre, an mheicníocht a cheadaigh uair amháin don líonra díláraithe Ethereum teacht ar chomhdhearcadh (i.e. gach nód ar aon dearcadh) ar rudaí mar iarmhéideanna cuntais agus ord na n-idirbheart. Chuir sé seo cosc ​​​​ar úsáideoirí "caitheamh dúbailte" a dhéanamh ar a gcuid bonn a agus chinntigh sé go raibh sé thar a bheith deacair slabhra Ethereum a ionsaí nó a ionramháil. Tagann na hairíonna slándála seo anois ó cruthúnas-gill ag baint úsáide as an meicníocht chomhthoil ar a dtugtar [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/). +Is é comhdhearcadh Nakamoto, a úsáideann cruthúnas-oibre, an mheicníocht a cheadaigh uair amháin don líonra díláraithe Ethereum teacht ar chomhdhearcadh (i.e., gach nód ar aon dearcadh) ar rudaí mar iarmhéideanna cuntais agus ord na n-idirbheart. Chuir sé seo cosc ​​​​ar úsáideoirí "caitheamh dúbailte" a dhéanamh ar a gcuid bonn a agus chinntigh sé go raibh sé thar a bheith deacair slabhra Ethereum a ionsaí nó a ionramháil. Tagann na hairíonna slándála seo anois ó cruthúnas-gill ag baint úsáide as an meicníocht chomhthoil ar a dtugtar [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/). ## Cruthúnas-oibre agus mianadóireacht {#pow-and-mining} From 786a2aea0deb28052a77c58016c20424c6f4580f Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:20:23 -0500 Subject: [PATCH 072/212] hard stops on consensus-mechanisms/pow/mining/index --- .../ga/developers/docs/consensus-mechanisms/pow/mining/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/index.md index cfd8cfb9fff..8029dc05164 100644 --- a/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/index.md +++ b/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -47,7 +47,7 @@ Tugann an méid seo a leanas forbhreathnú ar an gcaoi a ndearnadh idirbhearta a 2. Craolann an t-úsáideoir an t-iarratas idirbheart chuig líonra iomlán Ethereum ó roinnt [nód](/developers/docs/nodes-and-clients/). 3. Nuair a chloiseann siad faoin iarratas ar idirbheart nua, cuireann gach nód i líonra Ethereum an t-iarratas chuig a mempool áitiúil, liosta de na hiarratais uile ar idirbhirt a chuala siad faoi nach bhfuil geallta fós don blocshlabhra i mbloc. 4. Ag pointe éigin, comhiomlánaíonn nód mianadóireachta roinnt dosaen nó céadta iarratas idirbhirt ina [mbloc](/developers/docs/blocks/) féideartha, ar bhealach a uasmhéadaíonn an [táillí idirbhirt](/developers/docs/gas/) a thuilleann siad fad a fhanann siad faoin teorainn bhlocgháis. Déanann an nód mianadóireachta ansin: - 1. Fíoraíonn sé bailíocht gach iarratas idirbhirt (i.e. níl aon duine ag iarraidh éitear a aistriú amach as cuntas nár tháirg siad síniú dó, níl an t-iarratas míchumtha, etc.), agus ansin déanann sé cód an iarratais a fhorghníomhú, ag athrú an staid a gcóip áitiúil den EVM. Bronnann an mianadóir táille idirbhirt gach iarratas idirbhirt dá leithéid ar a chuntas féin. + 1. Fíoraíonn sé bailíocht gach iarratas idirbhirt (i.e., níl aon duine ag iarraidh éitear a aistriú amach as cuntas nár tháirg siad síniú dó, níl an t-iarratas míchumtha, etc.), agus ansin déanann sé cód an iarratais a fhorghníomhú, ag athrú an staid a gcóip áitiúil den EVM. Bronnann an mianadóir táille idirbhirt gach iarratas idirbhirt dá leithéid ar a chuntas féin. 2. Cuirtear tús leis an bpróiseas chun an “deimhniú dlisteanachta” cruthúnas-oibre a tháirgeadh don bhloc féideartha, a luaithe a bheidh gach iarratas idirbhirt sa bhloc fíoraithe agus curtha i gcrích ar an gcóip EVM áitiúil. 5. Faoi dheireadh, críochnóidh mianadóir deimhniú a tháirgeadh le haghaidh bloc a chuimsíonn ár n-iarratas idirbhirt sonrach. Ansin craolann an mianadóir an bloc críochnaithe, lena n-áirítear an deimhniú agus seic ar an stát EVM nua a éilítear. 6. Cluineann nóid eile faoin mbloc nua. Deimhníonn siad an deimhniú, déanann siad gach idirbheart ar an mbloc iad féin (lena n-áirítear an t-idirbheart a chraol ár n-úsáideoir ar dtús), agus deimhníonn siad go bhfuil suim sheiceála a staid EVM nua tar éis na hidirbhearta go léir a chur i gcrích ag teacht le suim sheiceála na staide arna éileamh ag bloc an mhianadóir. Is ansin amháin a dhéanann na nóid seo an bloc seo a cheangal le heireaball a mblocshlabhra, agus glacadh leis an staid EVM nua mar an staid chanónach. From dd064683740fd85995bffa72c7122feae548f384 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:20:38 -0500 Subject: [PATCH 073/212] hard stops on mining-algorithms/index --- .../consensus-mechanisms/pow/mining/mining-algorithms/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md index a59d44c5240..a9988b23590 100644 --- a/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md +++ b/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -20,7 +20,7 @@ Ba algartam taighde réamhtheachtaithe é Dagger Hashimoto do mhianadóireacht E Baineann [Dagger](http://www.hashcash.org/papers/dagger.html) le giniúint [>Graf Neamhchioglach Dírithe](https://en.wikipedia.org/wiki/Directed_acyclic_graph), a ndéantar slisní randamacha de a ghreamú le chéile. Is é an bunphrionsabal ná nach n-éilíonn gach nonce ach cuid bheag de chrann mór sonraí iomlán. Tá sé ródhaor don mhianadóireacht an fochrainn a athríomh do gach nonce - mar sin is gá an crann a stóráil - ach tá ceart go leor le haghaidh fíorú aonuaire. Ceapadh Dagger mar mhalairt ar algartaim atá ann cheana féin cosúil le Scrypt, atá crua ar chuimhne ach deacair a fhíorú nuair a mhéadaíonn a gcruas chuimhne go leibhéil atá slán i ndáiríre. Mar sin féin, bhí Dagger i mbaol luasghéarú crua-earraí cuimhne roinnte agus thit sé i bhfabhar bealaí eile taighde. -Is algartam é [Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) a chuireann friotaíocht ASIC leis trí bheith faoi cheangal I/O (i.e. léann an chuimhne an fachtóir teorannaithe sa phróiseas mianadóireachta). Is é an teoiric go bhfuil RAM ar fáil níos mó ná ríomh; tá imscrúdú déanta cheana ar RAM a bharrfheabhsú do chásanna úsáide éagsúla ar chostas na mbilliún dollar de thaighde, a mbíonn patrúin rochtana gar-randamach i gceist leo go minic (mar sin “cuimhne rochtana randamach”). Mar thoradh air sin, is dócha go mbeidh an RAM atá ann cheana féin measartha gar don bharrmhaith chun an algartam a mheas. Úsáideann Hashimoto an blocshlabhra mar fhoinse sonraí, ag sásamh (1) agus (3) thuas ag an am céanna. +Is algartam é [Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) a chuireann friotaíocht ASIC leis trí bheith faoi cheangal I/O (i.e., léann an chuimhne an fachtóir teorannaithe sa phróiseas mianadóireachta). Is é an teoiric go bhfuil RAM ar fáil níos mó ná ríomh; tá imscrúdú déanta cheana ar RAM a bharrfheabhsú do chásanna úsáide éagsúla ar chostas na mbilliún dollar de thaighde, a mbíonn patrúin rochtana gar-randamach i gceist leo go minic (mar sin “cuimhne rochtana randamach”). Mar thoradh air sin, is dócha go mbeidh an RAM atá ann cheana féin measartha gar don bharrmhaith chun an algartam a mheas. Úsáideann Hashimoto an blocshlabhra mar fhoinse sonraí, ag sásamh (1) agus (3) thuas ag an am céanna. D'úsáid Dagger-Hashimoto leaganacha leasaithe de na halgartaim Dagger agus Hashimoto. Is é an difríocht idir Dagger Hashimoto agus Hashimoto ná, in ionad an blocshlabhra a úsáid mar fhoinse sonraí, úsáideann Dagger Hashimoto tacar sonraí saincheaptha-ghinte, a thugann cothrom le dáta bunaithe ar shonraí bloc gach N bloic. Gintear an tacar sonraí trí úsáid a bhaint as algartam Dagger, a cheadaíonn fo-thacar a bhaineann go sonrach le gach nonce don algartam fíoraithe cliant éadrom a ríomh go héifeachtach. Is é an difríocht idir Dagger Hashimoto agus Dagger ná, murab ionann agus an Dagger bunaidh, go bhfuil an tacar sonraí a úsáidtear chun an bloc a fhiosrú leathbhuan, agus nach ndéantar é a nuashonrú ach ó am go ham (m.sh. uair sa tseachtain). Ciallaíonn sé seo go bhfuil an chuid den iarracht chun an tacar sonraí a ghiniúint gar do nialas, agus mar sin bíonn argóintí Sergio Lerner maidir le luasanna cuimhne roinnte diomaibhseach. From 2ce3b37d945ffe9a874ced59fe7f2be45d06c14c Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:20:50 -0500 Subject: [PATCH 074/212] hard stops on data-availability/index --- .../ga/developers/docs/data-availability/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/translations/ga/developers/docs/data-availability/index.md b/public/content/translations/ga/developers/docs/data-availability/index.md index 7a77dcdc5e0..29aa2effc6c 100644 --- a/public/content/translations/ga/developers/docs/data-availability/index.md +++ b/public/content/translations/ga/developers/docs/data-availability/index.md @@ -46,7 +46,7 @@ Is é an chaoi a n-oibríonn na cruthúnais chalaoise seo ná go bhféadfadh nó Braitheann sé seo ar rochtain a bheith ag nóid iomlána ar shonraí iomlána idirbhirt. Bheadh ​​​​ionsaitheoir a chraolann ceanntásc droch-bhloic agus a mhainníonn freisin na sonraí idirbhirt a chur ar fáil in ann nóid iomlána a chosc ó chruthúnas calaoise a ghiniúint. B'fhéidir go mbeadh na nóid iomlána in ann rabhadh a thabhairt faoi dhroch-bhloc, ach níorbh fhéidir leo tacú lena rabhadh le cruthúnas, mar níor cuireadh na sonraí ar fáil chun an cruthúnas a ghiniúint uaidh! -Is é DAS an réiteach ar an bhfadhb infhaighteachta sonraí seo. Íoslódálann nóid éadroma sleachta randamacha an-bheaga de na sonraí staide iomlána agus úsáideann siad na samplaí chun a fhíorú go bhfuil an tacar sonraí iomlán ar fáil. Is féidir an dóchúlacht iarbhír a bhaineann le hinfhaighteacht sonraí iomlána a ghlacadh go mícheart tar éis N smután randamach a íoslódáil a ríomh ([ i gcás 100 smután is é an seans ná 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), i.e. dóchúlacht dhochreidte beagnach). +Is é DAS an réiteach ar an bhfadhb infhaighteachta sonraí seo. Íoslódálann nóid éadroma sleachta randamacha an-bheaga de na sonraí staide iomlána agus úsáideann siad na samplaí chun a fhíorú go bhfuil an tacar sonraí iomlán ar fáil. Is féidir an dóchúlacht iarbhír a bhaineann le hinfhaighteacht sonraí iomlána a ghlacadh go mícheart tar éis N smután randamach a íoslódáil a ríomh ([ i gcás 100 smután is é an seans ná 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), i.e., dóchúlacht dhochreidte beagnach). Fiú sa chás seo, d'fhéadfadh sé nach dtabharfadh cliaint a dhéanann iarratais sonraí randamacha ionsaithe a choinníonn siar cúpla beart faoi deara. Ceartaítear é seo le códú scriosta trí phíosaí beaga sonraí atá in easnamh a athchruthú chun athruithe staide atá beartaithe a sheiceáil. D'fhéadfaí cruthúnas calaoise a chruthú ansin ag baint úsáide as na sonraí atógtha, rud a chuirfeadh cosc ​​ar nóid éadroma glacadh le droch-cheanntáisc. @@ -58,7 +58,7 @@ Fiú sa chás seo, d'fhéadfadh sé nach dtabharfadh cliaint a dhéanann iarrata Mar sin féin, ní féidir muinín a chur sna hidirbhearta 'achomair' a phostáiltear chuig Ethereum más féidir an t-athrú staide atá beartaithe a fhíorú agus a dhearbhú go neamhspleách mar thoradh ar na hidirbhearta aonair as slabhra go léir a chur i bhfeidhm. Mura gcuireann oibreoirí rolladh suas na sonraí idirbhirt ar fáil don fhíorú seo, d'fhéadfadh siad sonraí míchearta a sheoladh chuig Ethereum. -Postálann [Rollaí dóchasacha](/developers/docs/scaling/optimistic-rollups/) sonraí idirbheart comhbhrúite chuig Ethereum agus fanann ar feadh roinnt ama (7 lá go hiondúil) chun ligean d’fhíoraitheoirí neamhspleácha na sonraí a sheiceáil. Má aithníonn aon duine fadhb, is féidir leo cruthúnas calaoise a ghiniúint agus é a úsáid chun dúshlán a thabhairt don rolladh suas. Chuirfeadh sé seo faoi deara an slabhra a rolladh siar agus an bloc neamhbhailí a fhágáil ar lár. Ní féidir é seo a dhéanamh ach amháin má tá sonraí ar fáil. Faoi láthair, tá dhá bhealach ann a chuireann rolladh suas dóchasach sonraí idirbhirt chuig L1. Cuireann roinnt rolluithe sonraí ar fáil go buan mar `CALLDATA` a mhaireann go buan ar slabhra. Le cur i bhfeidhm EIP-4844, cuireann roinnt rollaí suas a gcuid sonraí idirbheart chuig stóráil blobaí níos saoire ina ionad sin. Ní stóráil bhuan é seo. Caithfidh fíoraitheoirí neamhspleácha na blobaí a fhiosrú agus a ndúshlán a ardú laistigh de ~18 lá sula scriostar na sonraí ó Ethereum ciseal-1. Ní ráthaítear infhaighteacht sonraí ach ag prótacal Ethereum don fhuinneog ghearr sheasta sin. Tar éis sin, bíonn aonáin eile in éiceachóras Ethereum freagrach as. Is féidir le haon nód infhaighteacht sonraí a fhíorú trí úsáid a bhaint as DAS, i.e. trí shamplaí beaga randamacha de shonraí blobaí a íoslódáil. +Postálann [Rollaí dóchasacha](/developers/docs/scaling/optimistic-rollups/) sonraí idirbheart comhbhrúite chuig Ethereum agus fanann ar feadh roinnt ama (7 lá go hiondúil) chun ligean d’fhíoraitheoirí neamhspleácha na sonraí a sheiceáil. Má aithníonn aon duine fadhb, is féidir leo cruthúnas calaoise a ghiniúint agus é a úsáid chun dúshlán a thabhairt don rolladh suas. Chuirfeadh sé seo faoi deara an slabhra a rolladh siar agus an bloc neamhbhailí a fhágáil ar lár. Ní féidir é seo a dhéanamh ach amháin má tá sonraí ar fáil. Faoi láthair, tá dhá bhealach ann a chuireann rolladh suas dóchasach sonraí idirbhirt chuig L1. Cuireann roinnt rolluithe sonraí ar fáil go buan mar `CALLDATA` a mhaireann go buan ar slabhra. Le cur i bhfeidhm EIP-4844, cuireann roinnt rollaí suas a gcuid sonraí idirbheart chuig stóráil blobaí níos saoire ina ionad sin. Ní stóráil bhuan é seo. Caithfidh fíoraitheoirí neamhspleácha na blobaí a fhiosrú agus a ndúshlán a ardú laistigh de ~18 lá sula scriostar na sonraí ó Ethereum ciseal-1. Ní ráthaítear infhaighteacht sonraí ach ag prótacal Ethereum don fhuinneog ghearr sheasta sin. Tar éis sin, bíonn aonáin eile in éiceachóras Ethereum freagrach as. Is féidir le haon nód infhaighteacht sonraí a fhíorú trí úsáid a bhaint as DAS, i.e., trí shamplaí beaga randamacha de shonraí blobaí a íoslódáil. Ní gá do [Rollú suas nialais-eolas (ZK)](/developers/docs/scaling/zk-rollups) sonraí idirbhirt a phostáil ós rud é go ráthaíonn [cruthúnais bailíochta nialais-eolais](/glossary/#zk-proof) cruinneas na n-aistrithe staide. Mar sin féin, tá infhaighteacht sonraí fós ina cheist toisc nach féidir linn feidhmiúlacht an rollú suas ZK (nó idirghníomhú leis) a ráthú gan rochtain ar a shonraí staide. Mar shampla, ní bheidh a n-iarmhéideanna ar eolas ag úsáideoirí má choinníonn oibreoir sonraí siar faoi staid an rollta suas. Chomh maith leis sin, ní féidir leo nuashonruithe staide a dhéanamh ag baint úsáide as faisnéis atá i mbloc atá curtha leis go nua. From 4bcdcfe2f380ae58db55b6a240d6b31ea7a58702 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:21:00 -0500 Subject: [PATCH 075/212] hard stops on gas/index --- public/content/translations/ga/developers/docs/gas/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/translations/ga/developers/docs/gas/index.md b/public/content/translations/ga/developers/docs/gas/index.md index e5c8ba34435..b3750e41841 100644 --- a/public/content/translations/ga/developers/docs/gas/index.md +++ b/public/content/translations/ga/developers/docs/gas/index.md @@ -45,7 +45,7 @@ Bheadh ​​an táille iomlán cothrom anois le: nuair is luach é an `buntáille` atá socraithe ag an bprótacal agus gur luach é an `táille tosaíochta` a shocraíonn an t-úsáideoir mar leid don bhailíochtóir. -i.e. `21,000* (10+2) = 252,000 gwei` (0.000252 ETH). +i.e., `21,000* (10+2) = 252,000 gwei` (0.000252 ETH). Nuair a sheolann Jordáin an t-airgead, asbhainfear 1.000252 ETH ó chuntas Jordan. Cuirfear 1.0000 ETH chun sochair Taylor. Faigheann an bailíochtóir an barr 0.000042 ETH. Dóitear an `buntáille` de 0.00021 ETH. @@ -98,7 +98,7 @@ Is féidir leat a rá go follasach cé mhéad atá tú sásta a íoc chun d’id I mbeagán focal, cabhraíonn táillí gáis le líonra Ethereum a choinneáil slán. Trí tháille a éileamh ar gach ríomh a dhéantar ar an líonra, cuirimid cosc ​​ar dhroch-aisteoirí an líonra a thurscar. D'fhonn lúba gan teorainn trí thaisme nó naimhdeach nó cur amú ríomhaireachtúil eile sa chód a sheachaint, ní mór do gach idirbheart teorainn a shocrú maidir le cé mhéad céimeanna ríomhaireachtúla um rith an chóid is féidir leis a úsáid. Is é "gás" an bunaonad ríomhaireachtúil. -Cé go bhfuil teorainn san áireamh in idirbheart, cuirtear aon ghás nach n-úsáidtear in idirbheart ar ais chuig an úsáideoir (i.e. aischuirtear `uas-táille - (buntáille + leid)`). +Cé go bhfuil teorainn san áireamh in idirbheart, cuirtear aon ghás nach n-úsáidtear in idirbheart ar ais chuig an úsáideoir (i.e., aischuirtear `uas-táille - (buntáille + leid)`). ![Léaráid a thaispeánann conas a dhéantar gás neamhúsáidte a aisíoc](../transactions/gas-tx.png) _Léaráid oiriúnaithe ó [Ethereum EVM léirithe](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ From 14eb71114f2e1323cd6a84ba1b183e0fe7135c11 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:21:13 -0500 Subject: [PATCH 076/212] hard stops on networks/index --- .../content/translations/ga/developers/docs/networks/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/developers/docs/networks/index.md b/public/content/translations/ga/developers/docs/networks/index.md index 1596f41ace5..f429a4ae3f7 100644 --- a/public/content/translations/ga/developers/docs/networks/index.md +++ b/public/content/translations/ga/developers/docs/networks/index.md @@ -116,7 +116,7 @@ Líonra tástála le haghaidh [Starknet](https://www.starknet.io). ## Líonraí príobháideacha {#private-networks} -Is líonra príobháideach é líonra Ethereum mura bhfuil a nóid ceangailte le líonra poiblí (i.e. Mainnet nó testnet). Sa chomhthéacs seo, ní cihallaíonn príobháideach ach forchoimeádta nó leithlisithe, seachas faoi chosaint nó slán. +Is líonra príobháideach é líonra Ethereum mura bhfuil a nóid ceangailte le líonra poiblí (i.e., Mainnet nó testnet). Sa chomhthéacs seo, ní cihallaíonn príobháideach ach forchoimeádta nó leithlisithe, seachas faoi chosaint nó slán. ### Líonraí forbartha {#development-networks} From 2e7ff792c426a0289f28a523ec60519627289da6 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:21:27 -0500 Subject: [PATCH 077/212] hard stops on oracles/index --- .../translations/ga/developers/docs/oracles/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/translations/ga/developers/docs/oracles/index.md b/public/content/translations/ga/developers/docs/oracles/index.md index edf925fca66..5fa58ee5263 100644 --- a/public/content/translations/ga/developers/docs/oracles/index.md +++ b/public/content/translations/ga/developers/docs/oracles/index.md @@ -14,7 +14,7 @@ Glacann an leathanach seo leis go bhfuil an léitheoir eolach ar bhunghnéithe E ## Cad is oracal blocshlabhra ann? {#what-is-a-blockchain-oracle} -Is feidhmchláir iad Oracail a fhoinsíonn, a fhíoraíonn agus a tharchuireann faisnéis sheachtrach (i.e. faisnéis a stóráiltear as slabhra) chuig conarthaí cliste a ritheann ar an mblocshlabhra. Chomh maith le sonraí a "tharraingt" as slabhra agus é a chraoladh ar Ethereum, is féidir le horacail faisnéis a “bhrú” ón mBlocshlabhra chuig córais sheachtracha, m.sh. glas cliste a dhíghlasáil a luaithe a sheolann an t-úsáideoir táille trí idirbheart Ethereum. +Is feidhmchláir iad Oracail a fhoinsíonn, a fhíoraíonn agus a tharchuireann faisnéis sheachtrach (i.e., faisnéis a stóráiltear as slabhra) chuig conarthaí cliste a ritheann ar an mblocshlabhra. Chomh maith le sonraí a "tharraingt" as slabhra agus é a chraoladh ar Ethereum, is féidir le horacail faisnéis a “bhrú” ón mBlocshlabhra chuig córais sheachtracha, m.sh. glas cliste a dhíghlasáil a luaithe a sheolann an t-úsáideoir táille trí idirbheart Ethereum. Gan oracal, bheadh ​​conradh cliste teoranta go hiomlán do shonraí ar slabhra. @@ -32,7 +32,7 @@ Chun forghníomhú cinntitheach a bhaint amach, teorannaíonn blocshlabhra nóid - “An bhfuil go leor cistí ag an gcuntas seo chun an t-idirbheart a chlúdach?” - “An bhfuil an t-idirbheart seo bailí i gcomhthéacs an chonartha chliste seo?”, etc. -Dá bhfaigheadh ​​blocshlabhra faisnéis ó fhoinsí seachtracha (i.e. ón bhfíorshaol), bheadh ​​sé dodhéanta cinntitheacht a bhaint amach, rud a chuirfeadh cosc ​​ar nóid aontú ar bhailíocht athruithe ar staid na blocshlabhra. Tóg mar shampla conradh cliste a ritheann idirbheart bunaithe ar an ráta malairte ETH-USD reatha a fhaightear ó API praghais traidisiúnta. Is dócha go n-athróidh an figiúr seo go minic (gan trácht ar go bhféadfaí an API a dhímholadh nó a haiceáil), rud a chiallaíonn go dtiocfadh torthaí éagsúla ar nóid a fhorghníomhaíonn an cód conartha céanna. +Dá bhfaigheadh ​​blocshlabhra faisnéis ó fhoinsí seachtracha (i.e., ón bhfíorshaol), bheadh ​​sé dodhéanta cinntitheacht a bhaint amach, rud a chuirfeadh cosc ​​ar nóid aontú ar bhailíocht athruithe ar staid na blocshlabhra. Tóg mar shampla conradh cliste a ritheann idirbheart bunaithe ar an ráta malairte ETH-USD reatha a fhaightear ó API praghais traidisiúnta. Is dócha go n-athróidh an figiúr seo go minic (gan trácht ar go bhféadfaí an API a dhímholadh nó a haiceáil), rud a chiallaíonn go dtiocfadh torthaí éagsúla ar nóid a fhorghníomhaíonn an cód conartha céanna. I gcás blocshlabhra poiblí cosúil le Ethereum, ina bhfuil na mílte nód ar fud an domhain ag próiseáil idirbhearta, tá cinntitheacht ríthábhachtach. Gan aon údarás lárnach ag feidhmiú mar fhoinse na fírinne, tá meicníochtaí ag teastáil ó nóid chun teacht ar an staid chéanna tar éis na hidirbhearta céanna a chur i bhfeidhm. Má ritheann nód A cód conartha cliste agus go bhfaigheann sé “3” mar thoradh air sin, cé go bhfaigheann nód B “7” tar éis an t-idirbheart céanna a rith, bheadh ​​comhaontú ann chun luach Ethereum a bhriseadh síos mar ardán ríomhaireachta díláraithe agus é a dhíchur. @@ -54,7 +54,7 @@ Léiríonn an “fhadhb oracal” mar a thugtar air na saincheisteanna a bhainea Tairgeann oracail éagsúla réitigh éagsúla ar fhadhb na n-oracal, a ndéanaimid iniúchadh orthu níos déanaí. De ghnáth déantar measúnú ar Oracail de réir chomh maith agus is féidir leo na dúshláin seo a leanas a láimhseáil: -1. **Cruinneas**: Níor cheart go gcuirfeadh oracal faoi deara go spreagfadh conarthaí cliste athruithe staide bunaithe ar shonraí neamhbhailí as slabhra. Caithfidh oracal _barántúlacht_ agus _sláine_ na sonraí a ráthú. Ciallaíonn barántúlacht go bhfuarthas na sonraí ón bhfoinse cheart, agus ciallaíonn sláine gur fhan na sonraí slán (i.e. níor athraíodh iad) sular seoladh iad ar slabhra. +1. **Cruinneas**: Níor cheart go gcuirfeadh oracal faoi deara go spreagfadh conarthaí cliste athruithe staide bunaithe ar shonraí neamhbhailí as slabhra. Caithfidh oracal _barántúlacht_ agus _sláine_ na sonraí a ráthú. Ciallaíonn barántúlacht go bhfuarthas na sonraí ón bhfoinse cheart, agus ciallaíonn sláine gur fhan na sonraí slán (i.e., níor athraíodh iad) sular seoladh iad ar slabhra. 2. **Infhaighteacht**: Níor cheart go gcuirfeadh oracal moill nó cosc ​​ar chonarthaí cliste ó ghníomhartha a dhéanamh agus athruithe staide a chur i bhfeidhm. Ciallaíonn sé seo go gcaithfidh sonraí ó oracal a bheith _ar fáil ach iad a iarraidh_ gan aon bhriseadh. @@ -256,7 +256,7 @@ Is meicníochtaí cripteagrafaíocha iad cruthúnais bharántúlachta a chumasa I measc samplaí de chruthúnais bharántúlachta tá: -**Cruthúnais Slándála Sraithe Iompair (TLS)**: Is minic a dhéanann nóid Oracle sonraí a aisghabháil ó fhoinsí seachtracha trí úsáid a bhaint as nasc slán HTTP bunaithe ar phrótacal Slándáil Sraithe Iompair(TLS). Úsáideann roinnt oracal díláraithe cruthúnais barántúlachta chun seisiúin TLS a fhíorú (i.e. malartú faisnéise idir nód agus freastalaí ar leith a dhearbhú) agus chun a dhearbhú nár athraíodh a bhfuil sa seisiún. +**Cruthúnais Slándála Sraithe Iompair (TLS)**: Is minic a dhéanann nóid Oracle sonraí a aisghabháil ó fhoinsí seachtracha trí úsáid a bhaint as nasc slán HTTP bunaithe ar phrótacal Slándáil Sraithe Iompair(TLS). Úsáideann roinnt oracal díláraithe cruthúnais barántúlachta chun seisiúin TLS a fhíorú (i.e., malartú faisnéise idir nód agus freastalaí ar leith a dhearbhú) agus chun a dhearbhú nár athraíodh a bhfuil sa seisiún. **Timpeallacht Fhianaithe Iontaofa Reatha (TEE)**: Is timpeallacht ríomhbhosca gainimh é [timpeallacht reatha iontaofa](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) atá scoite amach ó phróisis oibriúcháin a chórais óstaigh. Cinntíonn TEEanna go gcoimeádtar sláine, rúndacht agus neamh-inaistritheacht cibé cód feidhmchláir nó sonraí a stóráiltear/a úsáidtear sa timpeallacht ríomha. Is féidir le húsáideoirí fianú a ghiniúint freisin chun a chruthú go bhfuil ásc feidhmchláir ag rith laistigh den timpeallacht reatha iontaofa. From b6634bea7f7cd1ed24a3b2027997892ccc6929ec Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:21:45 -0500 Subject: [PATCH 078/212] hard stops on scaling/optimistic-rollups/index --- .../ga/developers/docs/scaling/optimistic-rollups/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/translations/ga/developers/docs/scaling/optimistic-rollups/index.md b/public/content/translations/ga/developers/docs/scaling/optimistic-rollups/index.md index 475be8a6c05..bd6eecdd856 100644 --- a/public/content/translations/ga/developers/docs/scaling/optimistic-rollups/index.md +++ b/public/content/translations/ga/developers/docs/scaling/optimistic-rollups/index.md @@ -118,7 +118,7 @@ Má dhéanann duine agóid in aghaidh dearbhaithe, ansin cuirfidh an prótacal u Déanann scéimeanna um chruthú idirghníomhach aon-bhabhta idirbhearta faoi dhíospóid a athimirt ar L1 chun dearbhuithe neamhbhailí a bhrath. Déanann an prótacal uas-scálaithe aithris ar ath-rith an idirbhirt faoi dhíospóid ar L1 (Ethereum) ag baint úsáide as conradh fíoraitheora, agus is é bunchloch an stáit ríofa a chinneann cé a bhuaigh an dúshlán. Má tá éileamh an iomaitheoir faoi staid cheart an uas-scálaithe i gceart, gearrtar pionós ar an oibreoir trína bhanna a ghearradh. -Mar sin féin, chun idirbhearta a ath-rith ar L1 chun calaois a bhrath ní mór gealltanais staide a fhoilsiú maidir le hidirbhearta aonair agus méadaítear ar na sonraí is gá do na huas-scáluithe a fhoilsiú ar slabhra. Tabhaítear costais shuntasacha gáis freisin le hidirbhearta athimeartha. Ar na cúiseanna seo, tá uas-scáluithe dóchasacha ag aistriú go cruthú idirghníomhach il-bhabhta, a bhaineann an cuspóir céanna amach (i.e. oibríochtaí rollup neamhbhailí a bhrath) le níos mó éifeachtúlachta. +Mar sin féin, chun idirbhearta a ath-rith ar L1 chun calaois a bhrath ní mór gealltanais staide a fhoilsiú maidir le hidirbhearta aonair agus méadaítear ar na sonraí is gá do na huas-scáluithe a fhoilsiú ar slabhra. Tabhaítear costais shuntasacha gáis freisin le hidirbhearta athimeartha. Ar na cúiseanna seo, tá uas-scáluithe dóchasacha ag aistriú go cruthú idirghníomhach il-bhabhta, a bhaineann an cuspóir céanna amach (i.e., oibríochtaí rollup neamhbhailí a bhrath) le níos mó éifeachtúlachta. #### Cruthú idirghníomhach il-bhabhta {#multi-round-interactive-proving} @@ -168,7 +168,7 @@ Tar éis an t-iarratas aistarraingthe a thionscnamh ar an uas-scálú L2, cuirte Ionas nach gá fanacht seachtain roimh airgead a aistarraingt chuig Ethereum, is féidir le húsáideoirí uas-scálú dóchasach **soláthraí leachtachta** (LP) a fhostú. Glacann soláthraí leachtachta úinéireacht ar aistarraingt L2 atá ar feitheamh agus íocann sé an t-úsáideoir ar L1 (mar mhalairt ar tháille). -Is féidir le soláthraithe leachtachta bailíocht iarratas aistarraingthe an úsáideora a sheiceáil (tríd an slabhra a rith iad féin) sula scaoiltear cistí. Ar an mbealach seo tá dearbhuithe acu go ndeimhneofar an t-idirbheart sa deireadh (i.e. críochnaitheacht gan iontaoibh). +Is féidir le soláthraithe leachtachta bailíocht iarratas aistarraingthe an úsáideora a sheiceáil (tríd an slabhra a rith iad féin) sula scaoiltear cistí. Ar an mbealach seo tá dearbhuithe acu go ndeimhneofar an t-idirbheart sa deireadh (i.e., críochnaitheacht gan iontaoibh). #### 2. Comhoiriúnacht EVM {#evm-compatibility} From 6dba31244abaf16fc8933c7d5e19c6332700a9f4 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:22:02 -0500 Subject: [PATCH 079/212] hard stops on scaling/plasma/index --- .../translations/ga/developers/docs/scaling/plasma/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/developers/docs/scaling/plasma/index.md b/public/content/translations/ga/developers/docs/scaling/plasma/index.md index e6137a126c1..7811c9ddf34 100644 --- a/public/content/translations/ga/developers/docs/scaling/plasma/index.md +++ b/public/content/translations/ga/developers/docs/scaling/plasma/index.md @@ -90,7 +90,7 @@ Ní mór bloic a bheith ar fáil má tá nóid le bheith in ann an bloc a íosl Cuidíonn infhaighteacht sonraí freisin le prótacail scálaithe slabhra a dhaingniú atá tógtha ar bhunchiseal Ethereum. Trí iallach a chur ar oibreoirí ar na slabhraí seo sonraí idirbheart a fhoilsiú ar Ethereum, is féidir le duine ar bith dúshlán a thabhairt do bhloic neamhbhailí trí chruthúnas calaoise a thógáil a thagraíonn do staid cheart an tslabhra. -Stórálann slabhraí plasma sonraí idirbhirt leis an oibreoir go príomha agus **ní fhoilsíonn siad aon sonraí ar Mainnet ** (i.e. seachas gealltanais stáit tréimhsiúla). Ciallaíonn sé seo go gcaithfidh úsáideoirí brath ar an oibreoir chun sonraí bloc a sholáthar más gá dóibh cruthúnais chalaoise a chruthú a thabharfadh dúshlán d'idirbhearta neamhbhailí. Má oibríonn an córas seo, is féidir le húsáideoirí i gcónaí úsáid a bhaint as cruthúnais calaoise chun cistí a fháil. +Stórálann slabhraí plasma sonraí idirbhirt leis an oibreoir go príomha agus **ní fhoilsíonn siad aon sonraí ar Mainnet ** (i.e., seachas gealltanais stáit tréimhsiúla). Ciallaíonn sé seo go gcaithfidh úsáideoirí brath ar an oibreoir chun sonraí bloc a sholáthar más gá dóibh cruthúnais chalaoise a chruthú a thabharfadh dúshlán d'idirbhearta neamhbhailí. Má oibríonn an córas seo, is féidir le húsáideoirí i gcónaí úsáid a bhaint as cruthúnais calaoise chun cistí a fháil. Tosaíonn an fhadhb nuair is é an t-oibreoir, ní hamháin aon úsáideoir, an páirtí atá ag gníomhú go mailíseach. Toisc gurb é an t-oibreoir amháin atá i gceannas ar an mblocshlabhra, tá níos mó dreasachta acu aistrithe staide neamhbhailí a chur chun cinn ar scála níos mó, mar shampla cistí a ghoid a bhaineann le húsáideoirí an slabhra plasma. From 4594fea47a5776880f1e0b18265e2f9f0053a7cd Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:22:17 -0500 Subject: [PATCH 080/212] hard stops on scaling/state-channels/index --- .../ga/developers/docs/scaling/state-channels/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/translations/ga/developers/docs/scaling/state-channels/index.md b/public/content/translations/ga/developers/docs/scaling/state-channels/index.md index 421195049a8..031e728a966 100644 --- a/public/content/translations/ga/developers/docs/scaling/state-channels/index.md +++ b/public/content/translations/ga/developers/docs/scaling/state-channels/index.md @@ -29,7 +29,7 @@ Tá cainéil piara-le-piara thar a bheith úsáideach do chásanna inar mian le Is fearr cur síos ar chainéal íocaíochta mar “mórleabhar dhá threo” arna chothabháil ag beirt úsáideoir i dteannta a chéile. Is é iarmhéid tosaigh an mhórleabhair suim na dtaiscí atá faoi ghlas sa chonradh ar slabhra le linn na céime oscailte cainéal. Is féidir aistrithe cainéal íocaíochta a dhéanamh ar an toirt agus gan baint ag an blocshlabhra iarbhír féin, ach amháin i gcás cruthú ar slabhra aon-uaire tosaigh agus dúnadh an chainéil faoi dheireadh. -Éilíonn nuashonruithe ar iarmhéid an mhórleabhair (i.e. staid an chainéil íocaíochta) ceadú gach páirtí sa chainéal. Meastar go bhfuil nuashonrú cainéil, sínithe ag gach rannpháirtí cainéil, tugtha chun críche, cosúil le hidirbheart ar Ethereum. +Éilíonn nuashonruithe ar iarmhéid an mhórleabhair (i.e., staid an chainéil íocaíochta) ceadú gach páirtí sa chainéal. Meastar go bhfuil nuashonrú cainéil, sínithe ag gach rannpháirtí cainéil, tugtha chun críche, cosúil le hidirbheart ar Ethereum. Bhí cainéil íocaíochta i measc na réitigh scálaithe is luaithe a dearadh chun gníomhaíocht ar slabhra chostasach idirghníomhaíochtaí simplí úsáideora a íoslaghdú (m.sh. aistrithe ETH, babhtálacha adamhacha, micrea-íocaíochtaí). Is féidir le rannpháirtithe cainéil méid neamhtheoranta d’idirbhearta láithreacha gan táille a dhéanamh idir a chéile fad is nach sáraíonn suim ghlan a n-aistrithe na comharthaí taiscthe. @@ -39,7 +39,7 @@ Seachas tacú le híocaíochtaí as slabhra, ní raibh cainéil íocaíochta ús Tá go leor i gcoiteann fós ag cainéil staide agus cainéil íocaíochta. Mar shampla, idirghníomhaíonn úsáideoirí trí theachtaireachtaí sínithe go cripteagrafach (idirbhearta) a mhalartú, nach mór do rannpháirtithe an chainéil eile a shíniú freisin. Mura bhfuil nuashonrú staide molta sínithe ag na rannpháirtithe go léir, meastar é a bheith neamhbhailí. -Mar sin féin, chomh maith le hiarmhéideanna an úsáideora a choinneáil, rianaíonn an cainéal staid reatha stórais an chonartha (i.e. luachanna athróg conartha). +Mar sin féin, chomh maith le hiarmhéideanna an úsáideora a choinneáil, rianaíonn an cainéal staid reatha stórais an chonartha (i.e., luachanna athróg conartha). Mar sin is féidir conradh cliste a rith as slabhra idir dhá úsáideoir. Sa chás seo, ní theastaíonn ach ceadú na bpiaraí a chruthaigh an cainéal le haghaidh nuashonruithe ar staid inmheánach an chonartha chliste. @@ -191,9 +191,9 @@ I measc na gcásanna úsáide féideartha eile le haghaidh aipeanna cainéal sta ### Aistrithe adamhacha {#atomic-transfers} -Bhí cainéil luathíocaíochta teoranta d'aistrithe idir dhá pháirtí, rud a chuir srian lena n-in-úsáidteacht. Mar sin féin, thug bunú na gcainéil fhíorúla deis do dhaoine aonair aistrithe a dhéanamh trí idirghabhálaithe (i.e. ilchainéil p2p) gan a bheith orthu cainéal nua a oscailt. +Bhí cainéil luathíocaíochta teoranta d'aistrithe idir dhá pháirtí, rud a chuir srian lena n-in-úsáidteacht. Mar sin féin, thug bunú na gcainéil fhíorúla deis do dhaoine aonair aistrithe a dhéanamh trí idirghabhálaithe (i.e., ilchainéil p2p) gan a bheith orthu cainéal nua a oscailt. -Tugtar “aistrithe multi-hop” orthu go coitianta, tá íocaíochtaí ródaithe adamhach (i.e. éiríonn le gach cuid den idirbheart nó teipeann sé ar fad). Úsáideann aistrithe adamhacha [Haiseanna Conarthaí Glais Ama(HTLCs)](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts) chun a chinntiú nach scaoiltear an íocaíocht ach amháin má chomhlíontar coinníollacha áirithe, rud a laghdaíonn an riosca contrapháirtí. +Tugtar “aistrithe multi-hop” orthu go coitianta, tá íocaíochtaí ródaithe adamhach (i.e., éiríonn le gach cuid den idirbheart nó teipeann sé ar fad). Úsáideann aistrithe adamhacha [Haiseanna Conarthaí Glais Ama(HTLCs)](https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts) chun a chinntiú nach scaoiltear an íocaíocht ach amháin má chomhlíontar coinníollacha áirithe, rud a laghdaíonn an riosca contrapháirtí. ## Míbhuntáistí a bhaineann le cainéil staide a úsáid {#drawbacks-of-state-channels} From 5a752f2248aef6bdf3b8483c5731c971bed742d5 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:22:35 -0500 Subject: [PATCH 081/212] hard stops on scaling/zk-rollups/index --- .../ga/developers/docs/scaling/zk-rollups/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/translations/ga/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/ga/developers/docs/scaling/zk-rollups/index.md index 724b18c1d65..d5431e574d7 100644 --- a/public/content/translations/ga/developers/docs/scaling/zk-rollups/index.md +++ b/public/content/translations/ga/developers/docs/scaling/zk-rollups/index.md @@ -120,7 +120,7 @@ Nuair a bhíonn dóthain idirbheart ag an nód ZK-rollup, comhiomlánaíonn sé - Fréamh crann Merkle a chuimsíonn na hidirbhearta go léir sa bhaisc. - Cruthuithe Merkle maidir le hidirbhearta chun cuimsiú sa bhaisc a chruthú. - Tá cruthúnais Merkle do gach péire seoltóir-glacadóir in idirbhearta chun na cuntais sin a chruthú mar chuid de chrann staide an uas-scálaithe. -- Sraith fréamhacha stáit idirmheánacha, a dhíorthaítear ón bhfréamh staide a nuashonrú tar éis nuashonruithe staide a chur i bhfeidhm do gach idirbheart (i.e. cuntais seoltóra a laghdú agus cuntais glacadóra a mhéadú). +- Sraith fréamhacha stáit idirmheánacha, a dhíorthaítear ón bhfréamh staide a nuashonrú tar éis nuashonruithe staide a chur i bhfeidhm do gach idirbheart (i.e., cuntais seoltóra a laghdú agus cuntais glacadóra a mhéadú). Ríomhann an ciorcad cruthaithe an cruthúnas bailíochta trí "lúb" thar gach idirbheart agus déanann sé na seiceálacha céanna a rinne an t-oibreoir roimh phróiseáil an idirbhirt. Ar an gcéad dul síos, fíoraíonn sé go bhfuil cuntas an tseoltóra mar chuid den fhréamh staide atá ann cheana ag baint úsáide as an cruthúnas Merkle a sholáthraítear. Ansin laghdaíonn sé iarmhéid an tseoltóra, méadaíonn sé a nonce, haiseálann na sonraí cuntais nuashonraithe agus comhcheanglaíonn sé le cruthúnas Merkle chun fréamh Merkle nua a ghiniúint. @@ -136,9 +136,9 @@ Déanann an ciorcad ZK-proving atriail thar an bhaisc idirbheart ar fad, ag fío Tar éis don chiorcad cruthaithe cruinneas na nuashonruithe staide a fhíorú, cuireann an t-oibreoir L2 an cruthúnas bailíochta ríofa chuig an gconradh fíoraitheora ar L1. Fíoraíonn ciorcad fíoraithe an chonartha bailíocht an chruthúnais agus seiceálann sé freisin ionchuir phoiblí atá mar chuid den chruthúnas: -- **Fréamh réamhstaide**: Seanfhréamh staide an ZK-rollup (i.e. sular cuireadh na hidirbhearta baisce i gcrích), ag léiriú staid bhailí deiridh an tslabhra L2. +- **Fréamh réamhstaide**: Seanfhréamh staide an ZK-rollup (i.e., sular cuireadh na hidirbhearta baisce i gcrích), ag léiriú staid bhailí deiridh an tslabhra L2. -- **Fréamh iar-staide**: Fréamh staide nua an ZK-rollup (i.e. tar éis na hidirbhearta baisce a chur i gcrích), a léiríonn an staid is nuaí sa slabhra L2. Is é an fhréamh iar-staide an fhréamh dheiridh a dhíorthaítear tar éis nuashonruithe staide a chur i bhfeidhm sa chiorcad cruthaithe. +- **Fréamh iar-staide**: Fréamh staide nua an ZK-rollup (i.e., tar éis na hidirbhearta baisce a chur i gcrích), a léiríonn an staid is nuaí sa slabhra L2. Is é an fhréamh iar-staide an fhréamh dheiridh a dhíorthaítear tar éis nuashonruithe staide a chur i bhfeidhm sa chiorcad cruthaithe. - **Fréamh an bhaisc**: Fréamh Merkle na baisce, a dhíorthaítear trí _fhréamhú Merkle_ a dhéanamh ar na hidirbhearta sa bhaisc agus fréamh an chrainn a haiseáil. @@ -178,7 +178,7 @@ Táthar ag súil go gcabhróidh tabhairt isteach ZK-rollups atá comhoiriúnach Tá an méid a íocann úsáideoirí as idirbhearta ar ZK-rollups ag brath ar an táille gháis, díreach mar atá ar Ethereum Mainnet. Mar sin féin, oibríonn táillí gáis ar bhealach difriúil ar L2 agus bíonn tionchar ag na costais seo a leanas orthu: -1. ** Scríobh Staide**: Tá costas seasta ar scríobh chuig staid Ethereum (i.e. idirbheart a chur isteach ar bhlocshlabhra Ethereum). Laghdaíonn ZK-rollups an costas seo trí idirbhearta a bhaisceadh agus costais sheasta a scaipeadh ar úsáideoirí iolracha. +1. ** Scríobh Staide**: Tá costas seasta ar scríobh chuig staid Ethereum (i.e., idirbheart a chur isteach ar bhlocshlabhra Ethereum). Laghdaíonn ZK-rollups an costas seo trí idirbhearta a bhaisceadh agus costais sheasta a scaipeadh ar úsáideoirí iolracha. 2. **Foilsiú sonraí**: Foilsíonn ZK-rollups sonraí staide do gach idirbheart chuig Ethereum mar `calldata`. Tá costais `calldata` á rialú faoi láthair ag [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), a shonraíonn costas 16 ghás le haghaidh beart neamh-nialasach agus 4 ghás le haghaidh beart nialasach de `calldata`, faoi seach. Bíonn tionchar ag an gcostas a íoctar ar gach idirbheart ar an méid `calldata` is gá a phostáil ar slabhra dó. From 445406eb3f51310a0e9d87096d3cecd4302f8bfc Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:22:48 -0500 Subject: [PATCH 082/212] hard stops on smart-contracts/anatomy/index --- .../ga/developers/docs/smart-contracts/anatomy/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/translations/ga/developers/docs/smart-contracts/anatomy/index.md b/public/content/translations/ga/developers/docs/smart-contracts/anatomy/index.md index ea73e14450e..ccc31605bf6 100644 --- a/public/content/translations/ga/developers/docs/smart-contracts/anatomy/index.md +++ b/public/content/translations/ga/developers/docs/smart-contracts/anatomy/index.md @@ -76,9 +76,9 @@ Lena rá go simplí, is féidir le feidhmeanna faisnéis a fháil nó faisnéis Tá dhá chineál glaonna feidhme ann: - `internal` – ní chruthaíonn siad seo glao EVM - - Ní féidir rochtain a fháil ar fheidhmeanna inmheánacha agus ar athróga staide ach go hinmheánach (i.e. ón taobh istigh den chonradh reatha nó de na conarthaí a eascraíonn as) + - Ní féidir rochtain a fháil ar fheidhmeanna inmheánacha agus ar athróga staide ach go hinmheánach (i.e., ón taobh istigh den chonradh reatha nó de na conarthaí a eascraíonn as) - `seachtrach` –cruthaíonn siad seo glao EVM - - Is cuid den chomhéadan conartha iad feidhmeanna seachtracha, rud a chiallaíonn gur féidir iad a ghlaoch ó chonarthaí eile agus trí idirbhearta. Ní féidir glaoch inmheánach a chur ar fheidhm sheachtrach `f` (i.e. ní oibríonn `f()`, ach oibríonn `this.f()`). + - Is cuid den chomhéadan conartha iad feidhmeanna seachtracha, rud a chiallaíonn gur féidir iad a ghlaoch ó chonarthaí eile agus trí idirbhearta. Ní féidir glaoch inmheánach a chur ar fheidhm sheachtrach `f` (i.e., ní oibríonn `f()`, ach oibríonn `this.f()`). Is féidir leo a bheith `poiblí` nó `príobháideach` freisin From 92d363d4ebad05a8e203e06d3d530af9f8aeb24a Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:23:01 -0500 Subject: [PATCH 083/212] hard stops on smart-contracts/composability/index --- .../ga/developers/docs/smart-contracts/composability/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/developers/docs/smart-contracts/composability/index.md b/public/content/translations/ga/developers/docs/smart-contracts/composability/index.md index f8274f2abe2..a9d6570e622 100644 --- a/public/content/translations/ga/developers/docs/smart-contracts/composability/index.md +++ b/public/content/translations/ga/developers/docs/smart-contracts/composability/index.md @@ -43,7 +43,7 @@ Feabhsaíonn idir-inoibritheacht idir comhpháirteanna den éiceachóras Ethereu Úsáidfimid sampla ó thrádáil arbatráiste chun buntáistí idir-inoibritheachta a léiriú: -Má tá comhartha ag trádáil níos airde ar `mhalartán A` ná ar`mhalartán B`, is féidir leat leas a bhaint as an difríocht praghais chun brabús a dhéanamh. Ní féidir leat é sin a dhéanamh, áfach, ach amháin má tá go leor caipitil agat chun an t-idirbheart a mhaoiniú (i.e. an chomhartha a cheannach ó `mhalartán B` agus é a dhíol ar `mhalartán A`). +Má tá comhartha ag trádáil níos airde ar `mhalartán A` ná ar`mhalartán B`, is féidir leat leas a bhaint as an difríocht praghais chun brabús a dhéanamh. Ní féidir leat é sin a dhéanamh, áfach, ach amháin má tá go leor caipitil agat chun an t-idirbheart a mhaoiniú (i.e., an chomhartha a cheannach ó `mhalartán B` agus é a dhíol ar `mhalartán A`). I gcás nach bhfuil go leor airgid agat chun an trádáil a chlúdach, d'fhéadfadh iasacht splaince a bheith oiriúnach. Tá [Iasachtaí splaince](/defi/#flash-loans) thar a bheith teicniúil, ach is é an bun-smaoineamh gur féidir leat sócmhainní a fháil ar iasacht (gan comhthaobhacht) agus iad a thabhairt ar ais laistigh de _idirbheart amháin_. From 7c1adb5cc9051026cfda3c2bbddd7b17831988a7 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:23:17 -0500 Subject: [PATCH 084/212] hard stops on smart-contracts/formal-verification/index --- .../smart-contracts/formal-verification/index.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/public/content/translations/ga/developers/docs/smart-contracts/formal-verification/index.md b/public/content/translations/ga/developers/docs/smart-contracts/formal-verification/index.md index 6d7c12e7f71..a9a1d6aebe3 100644 --- a/public/content/translations/ga/developers/docs/smart-contracts/formal-verification/index.md +++ b/public/content/translations/ga/developers/docs/smart-contracts/formal-verification/index.md @@ -12,7 +12,7 @@ Nuair a chuirtear i bhfeidhm é i gconarthaí cliste, féadann fíorú foirmiúi ## Cad is fíorú foirmiúil ann? {#what-is-formal-verification} -Tagraíonn fíorú foirmiúil don phróiseas chun cruinneas an chórais a mheas maidir le sonraíocht fhoirmiúil. I dtéarmaí níos simplí, cuireann fíorú foirmiúil ar ár gcumas seiceáil an sásaíonn iompar córais roinnt riachtanas (i.e. déanann sé an méid a theastaíonn uainn). +Tagraíonn fíorú foirmiúil don phróiseas chun cruinneas an chórais a mheas maidir le sonraíocht fhoirmiúil. I dtéarmaí níos simplí, cuireann fíorú foirmiúil ar ár gcumas seiceáil an sásaíonn iompar córais roinnt riachtanas (i.e., déanann sé an méid a theastaíonn uainn). Déantar cur síos ar iompraíochtaí ionchasacha an chórais (conradh cliste sa chás seo) trí úsáid a bhaint as samhaltú foirmiúil, agus cuireann teangacha sonraíochta ar chumas airíonna foirmiúla a chruthú. Is féidir le teicníochtaí fíoraithe foirmiúla a fhíorú ansin go gcomhlíonann feidhmiú an chonartha a shonraíocht agus go bhfaightear cruthúnas matamaitice maidir le cruinneas an chonartha. Nuair a shásaíonn conradh a shonraíocht, déantar cur síos air mar “ceart ó thaobh feidhme”, “ceart de réir dearadh”, nó “ceart trí thógáil”. @@ -28,11 +28,11 @@ Díríonn samhlacha ardleibhéil ar an gcaidreamh idir conarthaí cliste agus gn Os a choinne sin, díríonn samhlacha foirmiúla eile ar iompar íseal-leibhéil conradh cliste. Cé gur féidir le samhlacha ardleibhéil cuidiú le réasúnú faoi fheidhmiúlacht conartha, d'fhéadfadh go dteipfidh orthu sonraí a fháil faoi oibriú inmheánach an fheidhmithe. Cuireann samhlacha íseal-leibhéil amharc bosca bán i bhfeidhm ar anailís ríomhchlár agus braitheann siad ar léirithe ar leibhéal níos ísle d’fheidhmchláir chliste chonarthaí, amhail rianta clár agus [>sreabhghraif rialaithe](https://en.wikipedia.org/wiki/Control-flow_graph), le réasún a thabhairt faoi na hairíonna a bhaineann le conradh a chur i gcrích. -Meastar samhlacha íseal-leibhéil a bheith oiriúnach ós rud é gurb ionann iad agus forghníomhú iarbhír conartha cliste i dtimpeallacht forghníomhaithe Ethereum (i.e. an [EVM](/developers/docs/evm/)). Tá teicnící samhaltaithe íseal-leibhéil thar a bheith úsáideach chun airíonna criticiúla sábháilteachta a bhunú i gconarthaí cliste agus chun leochaileachtaí féideartha a bhrath. +Meastar samhlacha íseal-leibhéil a bheith oiriúnach ós rud é gurb ionann iad agus forghníomhú iarbhír conartha cliste i dtimpeallacht forghníomhaithe Ethereum (i.e., an [EVM](/developers/docs/evm/)). Tá teicnící samhaltaithe íseal-leibhéil thar a bheith úsáideach chun airíonna criticiúla sábháilteachta a bhunú i gconarthaí cliste agus chun leochaileachtaí féideartha a bhrath. ### Cad is sonraíocht fhoirmiúil ann? {#what-is-a-formal-specification} -Níl i sonraíocht ach ceanglas teicniúil nach mór do chóras áirithe a shásamh. Sa ríomhchlárú, léiríonn sonraíochtaí smaointe ginearálta faoi fheidhmiú cláir (i.e. cad ba cheart don chlár a dhéanamh). +Níl i sonraíocht ach ceanglas teicniúil nach mór do chóras áirithe a shásamh. Sa ríomhchlárú, léiríonn sonraíochtaí smaointe ginearálta faoi fheidhmiú cláir (i.e., cad ba cheart don chlár a dhéanamh). I gcomhthéacs conarthaí cliste, tagraíonn sonraíochtaí foirmiúla do _airíonna_ — tuairiscí foirmiúla ar na ceanglais nach mór do chonradh a chomhlíonadh. Déantar cur síos ar réadmhaoin dá leithéid mar “athraithigh” agus is ionann iad agus dearbhuithe loighciúla faoi fhorghníomhú conartha nach mór a bheith fíor faoi gach imthosca féideartha, gan aon eisceachtaí. @@ -72,7 +72,7 @@ Is féidir sonraíochtaí foirmiúla íseal-leibhéil a thabhairt mar airíonna Soláthraíonn [Loighic Hoare](https://en.wikipedia.org/wiki/Hoare_logic) sraith rialacha foirmiúla chun réasúnú a dhéanamh maidir le cruinneas clár, lena n-áirítear conarthaí cliste. Tá airí i stíl Hoare léirithe ag triar Hoare `{P}c{Q}`, áit a bhfuil `c` ina chlár agus `P` agus `Q` ina réamhchoinníollacha agus iarchoinníollacha ar staid an `c` (i.e., an clár), ar a tugtar go foirmiúil _réamhchoinníollacha_ agus _iarchoinníollacha_, faoi seach. -Is réamhchoinníoll é preideacáid a chuireann síos ar na coinníollacha a theastaíonn chun feidhm a rith i gceart; ní mór d'úsáideoirí a ghlaonn isteach sa chonradh an ceanglas seo a chomhlíonadh. Is éard is iarchoinníoll ann ná preideacáid a chuireann síos ar an gcoinníoll a bhunaíonn feidhm má dhéantar é a rith i gceart; is féidir le húsáideoirí a bheith ag súil go mbeidh an coinníoll seo fíor tar éis dóibh glaoch isteach sa bhfeidhm. Is preideacáid í _athróg_ i loighic Hoare a chaomhnaítear trí fheidhm a rith (i.e. ní athraíonn sé). +Is réamhchoinníoll é preideacáid a chuireann síos ar na coinníollacha a theastaíonn chun feidhm a rith i gceart; ní mór d'úsáideoirí a ghlaonn isteach sa chonradh an ceanglas seo a chomhlíonadh. Is éard is iarchoinníoll ann ná preideacáid a chuireann síos ar an gcoinníoll a bhunaíonn feidhm má dhéantar é a rith i gceart; is féidir le húsáideoirí a bheith ag súil go mbeidh an coinníoll seo fíor tar éis dóibh glaoch isteach sa bhfeidhm. Is preideacáid í _athróg_ i loighic Hoare a chaomhnaítear trí fheidhm a rith (i.e., ní athraíonn sé). Is féidir le sonraíochtaí i stíl hoare ráthaíocht a thabhairt do _páirtchruinneas_ nó _cruinneas iomlán_. Tá cur i bhfeidhm feidhm chonartha "ceart go páirteach" má bhíonn an réamhchoinníoll fíor sula gcuirtear an fheidhm i gcrích, agus má chuirtear deireadh leis an rith, tá an iarchoinníoll fíor freisin. Faightear cruthúnas ar chruinneas iomlán má bhíonn réamhchoinníoll fíor sula ritear an fheidhm, ráthaítear go dtiocfaidh deireadh leis an rith agus nuair a dhéantar amhlaidh, beidh an t-iarchoinníoll fíor. @@ -90,7 +90,7 @@ Déanann sonraíochtaí rian-bhunaithe cur síos ar oibríochtaí a aistríonn c Braitheann an cur chuige seo ar shamhail de chonarthaí cliste mar chórais aistrithe stáit le roinnt stát réamhshainithe (arna gcur síos ag athróga stáit) mar aon le sraith aistrithe réamhshainithe (arna gcur síos ag feidhmeanna conartha). Ina theannta sin, tá [sreabhghraf rialaithe](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/) (CFG), ar léiriú grafach é ar a sreabhadh forghníomhaithe an chláir, in úsáid go minic chun cur síos a dhéanamh ar shéimeantaic oibriúcháin conartha. Anseo, léirítear gach rian mar chonair ar an sreabhghraf rialaithe. -Go príomha, úsáidtear sonraíochtaí rianleibhéil chun réasúnú a dhéanamh ar phatrúin reatha inmheánach i gconarthaí cliste. Trí shonraíochtaí rianleibhéil a chruthú, dearbhaímid na cosáin reatha inghlactha (i.e. aistrithe staide) le haghaidh conradh cliste. Trí úsáid a bhaint as teicníochtaí, mar rith siombalach, is féidir linn a fhíorú go foirmiúil nach leanann an rith cosán nach bhfuil sainithe sa tsamhail fhoirmiúil. +Go príomha, úsáidtear sonraíochtaí rianleibhéil chun réasúnú a dhéanamh ar phatrúin reatha inmheánach i gconarthaí cliste. Trí shonraíochtaí rianleibhéil a chruthú, dearbhaímid na cosáin reatha inghlactha (i.e., aistrithe staide) le haghaidh conradh cliste. Trí úsáid a bhaint as teicníochtaí, mar rith siombalach, is féidir linn a fhíorú go foirmiúil nach leanann an rith cosán nach bhfuil sainithe sa tsamhail fhoirmiúil. Úsáidimis sampla de chonradh [DAO](/dao/) a bhfuil roinnt feidhmeanna inrochtana ag an bpobal aige chun cur síos a dhéanamh ar airíonna rianleibhéil. Anseo, glacaimid leis go gceadaíonn an conradh DAO d'úsáideoirí na hoibríochtaí seo a leanas a dhéanamh: @@ -168,7 +168,7 @@ Is cáilíocht an-inmhianaithe í an iontaofacht in aon chonradh cliste, go hái Is é tástáil cláir an modh is coitianta chun a chruthú go sásaíonn conradh cliste roinnt riachtanas. Is éard atá i gceist leis seo conradh a rith le sampla de na sonraí a bhfuiltear ag súil lena láimhseáil agus a iompraíocht a anailísiú. Má thugann an conradh na torthaí a bhfuiltear ag súil leo ar na sonraí samplacha ar ais, ansin beidh cruthúnas oibiachtúil ag na forbróirí ar a chruinneas. -Ní féidir leis an gcur chuige seo, áfach, rith ceart a chruthú do luachanna ionchuir nach cuid den sampla iad. Mar sin, d’fhéadfadh go gcabhródh tástáil conartha le fabhtanna a aimsiú (i.e. má theipeann ar roinnt cosán cóid na torthaí inmhianaithe a thabhairt ar ais le linn an reatha), ach **ní féidir leis an easpa fabhtanna** a chruthú go cinntitheach. +Ní féidir leis an gcur chuige seo, áfach, rith ceart a chruthú do luachanna ionchuir nach cuid den sampla iad. Mar sin, d’fhéadfadh go gcabhródh tástáil conartha le fabhtanna a aimsiú (i.e., má theipeann ar roinnt cosán cóid na torthaí inmhianaithe a thabhairt ar ais le linn an reatha), ach **ní féidir leis an easpa fabhtanna** a chruthú go cinntitheach. Os a choinne sin, is féidir le fíorú foirmiúil a chruthú go foirmiúil go sásaíonn conradh cliste ceanglais maidir le raon éigríochta reatha _gan_ an conradh a rith ar chor ar bith. Éilíonn sé seo sonraíocht fhoirmiúil a chruthú a dhéanann cur síos beacht ar iompraíochtaí conartha cearta agus samhail fhoirmiúil (matamaiticiúil) de chóras an chonartha a fhorbairt. Ansin is féidir linn nós imeachta promhála foirmiúil a leanúint chun comhsheasmhacht idir samhail an chonartha agus a shonraíocht a sheiceáil. From b6531423d7c68639f217b00a5582ccbd9398d0b2 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:23:35 -0500 Subject: [PATCH 085/212] hard stops on smart-contracts/security/index --- .../ga/developers/docs/smart-contracts/security/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/developers/docs/smart-contracts/security/index.md b/public/content/translations/ga/developers/docs/smart-contracts/security/index.md index a3a9ff6303a..cb4dfbe4cbb 100644 --- a/public/content/translations/ga/developers/docs/smart-contracts/security/index.md +++ b/public/content/translations/ga/developers/docs/smart-contracts/security/index.md @@ -262,7 +262,7 @@ Nochtann an conradh seo feidhm `aistarraing()` chun ligean d’úsáideoirí ETH 2. Seolann cistí chuig an seoladh glaonna 3. Athshocraíonn siad a n-iarmhéid go 0, rud a choscann aistarraingtí breise ón úsáideoir -Leanann an fheidhm `withdraw()` i gconradh `Victim` patrún “seiceálacha-idirghníomhaíochtaí-éifeachtaí”. Déanann sé _seiceáil_ má shásaítear na coinníollacha atá riachtanach don fhorghníomhú (i.e., tá cothromaíocht dhearfach ETH ag an úsáideoir) agus déanann sé an _idirghníomhaíocht_ em> trí ETH a sheoladh chuig seoladh an ghlaoiteora, sula gcuirtear _éifeachtaí_ an idirbhirt i bhfeidhm (i.e. iarmhéid an úsáideora a laghdú). +Leanann an fheidhm `withdraw()` i gconradh `Victim` patrún “seiceálacha-idirghníomhaíochtaí-éifeachtaí”. Déanann sé _seiceáil_ má shásaítear na coinníollacha atá riachtanach don fhorghníomhú (i.e., tá cothromaíocht dhearfach ETH ag an úsáideoir) agus déanann sé an _idirghníomhaíocht_ em> trí ETH a sheoladh chuig seoladh an ghlaoiteora, sula gcuirtear _éifeachtaí_ an idirbhirt i bhfeidhm (i.e., iarmhéid an úsáideora a laghdú). Má ghlaoitear `aistarraing()` ó chuntas faoi úinéireacht sheachtrach (EOA), feidhmíonn an fheidhm mar a bhíothas ag súil leis: seolann `msg.sender.call.value()` ETH chuig an nglaoiteoir. Mar sin féin, más cuntas conartha cliste é `msg.sender` glaonna `aistarraing()`, seolfar cistí trí úsáid a bhaint as `msg.sender.call.value()` agus spreagfar cód atá stóráilte ag an seoladh sin a rith. From f1966361b4a4555592613627b1b64d3304e5ff60 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:23:47 -0500 Subject: [PATCH 086/212] hard stops on smart-contracts/testing/index --- .../ga/developers/docs/smart-contracts/testing/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/translations/ga/developers/docs/smart-contracts/testing/index.md b/public/content/translations/ga/developers/docs/smart-contracts/testing/index.md index c1df16697b6..db2d8249b0b 100644 --- a/public/content/translations/ga/developers/docs/smart-contracts/testing/index.md +++ b/public/content/translations/ga/developers/docs/smart-contracts/testing/index.md @@ -110,9 +110,9 @@ function auctionEnd() external { Is conradh ceant simplí é seo atá deartha chun tairiscintí a fháil le linn na tréimhse tairisceana. Má thagann méadú ar an `TairiscintisAirde`, faigheann an tairgeoir is airde roimhe sin a gcuid airgid; Nuair a bheidh an tréimhse tairisceana thart, cuireann an `tairbhí` an conradh chun a gcuid airgid a fháil. -Chlúdódh tástálacha aonaid le haghaidh conradh mar seo feidhmeanna éagsúla a d’fhéadfadh úsáideoir a ghlaoch agus é ag idirghníomhú leis an gconradh. Sampla is ea tástáil aonaid a sheiceálann an féidir le húsáideoir tairiscint a chur isteach agus an ceant ar siúl (i.e. go n-éiríonn le glaonna ar `thairiscint()`) nó ceann a sheiceálann an féidir le húsáideoir tairiscint níos airde a chur isteach. ná an `TairiscintisAirde` reatha. +Chlúdódh tástálacha aonaid le haghaidh conradh mar seo feidhmeanna éagsúla a d’fhéadfadh úsáideoir a ghlaoch agus é ag idirghníomhú leis an gconradh. Sampla is ea tástáil aonaid a sheiceálann an féidir le húsáideoir tairiscint a chur isteach agus an ceant ar siúl (i.e., go n-éiríonn le glaonna ar `thairiscint()`) nó ceann a sheiceálann an féidir le húsáideoir tairiscint níos airde a chur isteach. ná an `TairiscintisAirde` reatha. -Cuidíonn tuiscint ar shreabhadh oibre oibríochta conarthaí freisin le tástálacha aonaid a scríobh a sheiceáil an gcomhlíonann an rith na ceanglais. Mar shampla, sonraítear sa chonradh ceant nach féidir le húsáideoirí tairiscintí a chur isteach nuair a bhíonn an ceant críochnaithe (i.e., nuair a bhíonn `AmscoirCeant` níos ísle ná `stampaama.bloic`). Mar sin, d’fhéadfadh forbróir tástáil aonaid a rith a sheiceálann an n-éireoidh nó an dteipfidh ar ghlaonna chuig an bhfeidhm `tairiscint()` nuair a bhíonn an ceant thart (i.e. nuair a bheidh `AmscoirCeant` > `` `stampaama.bloic ``). +Cuidíonn tuiscint ar shreabhadh oibre oibríochta conarthaí freisin le tástálacha aonaid a scríobh a sheiceáil an gcomhlíonann an rith na ceanglais. Mar shampla, sonraítear sa chonradh ceant nach féidir le húsáideoirí tairiscintí a chur isteach nuair a bhíonn an ceant críochnaithe (i.e., nuair a bhíonn `AmscoirCeant` níos ísle ná `stampaama.bloic`). Mar sin, d’fhéadfadh forbróir tástáil aonaid a rith a sheiceálann an n-éireoidh nó an dteipfidh ar ghlaonna chuig an bhfeidhm `tairiscint()` nuair a bhíonn an ceant thart (i.e., nuair a bheidh `AmscoirCeant` > `` `stampaama.bloic ``). ##### 2. Déan measúnú ar na boinn tuisceana go léir a bhaineann le rith conartha @@ -223,9 +223,9 @@ Tá sé iontach imscaradh ar líonra tástála tar éis tástáil a dhéanamh ar ## Tástáil vs fíorú foirmiúil {#testing-vs-formal-verification} -Cé go gcuidíonn an tástáil le deimhniú go dtugann conradh na torthaí a bhfuiltear ag súil leo ar ais do roinnt ionchuir sonraí, ní féidir leis a chruthú go cinntitheach an rud céanna maidir le hionchuir nach n-úsáidtear le linn tástálacha. Mar sin, ní féidir "cruinneas feidhmiúil" a ráthú le conradh cliste a thástáil (i.e. ní féidir a thaispeáint go n-iompraíonn ríomhchlár mar is gá do _gach tacar_ de luachanna ionchuir). +Cé go gcuidíonn an tástáil le deimhniú go dtugann conradh na torthaí a bhfuiltear ag súil leo ar ais do roinnt ionchuir sonraí, ní féidir leis a chruthú go cinntitheach an rud céanna maidir le hionchuir nach n-úsáidtear le linn tástálacha. Mar sin, ní féidir "cruinneas feidhmiúil" a ráthú le conradh cliste a thástáil (i.e., ní féidir a thaispeáint go n-iompraíonn ríomhchlár mar is gá do _gach tacar_ de luachanna ionchuir). -Is éard atá i bhfíorú foirmiúil ná cur chuige chun cruinneas bogearraí a mheas trí sheiceáil an bhfuil samhail fhoirmiúil den chlár ag teacht leis an tsonraíocht fhoirmiúil. Is ionann samhail fhoirmiúil agus léiriú teibí matamaitice ar chlár, agus sainmhíníonn sonraíocht fhoirmiúil airíonna cláir (i.e. dearbhuithe loighciúla faoi fheidhmiú an chláir). +Is éard atá i bhfíorú foirmiúil ná cur chuige chun cruinneas bogearraí a mheas trí sheiceáil an bhfuil samhail fhoirmiúil den chlár ag teacht leis an tsonraíocht fhoirmiúil. Is ionann samhail fhoirmiúil agus léiriú teibí matamaitice ar chlár, agus sainmhíníonn sonraíocht fhoirmiúil airíonna cláir (i.e., dearbhuithe loighciúla faoi fheidhmiú an chláir). Toisc go bhfuil airíonna scríofa i dtéarmaí matamaitice, is féidir a fhíorú go sásaíonn samhail fhoirmiúil (matamaiticiúil) den chóras sonraíocht agus úsáid á baint as rialacha loighciúla tátail. Mar sin, deirtear go dtugann uirlisí fíoraithe foirmiúla ‘cruthúnas matamaitice’ ar chruinneas córais. From 32725b911645ea5dbe8e43ddef48a5b8cc82b98b Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:23:59 -0500 Subject: [PATCH 087/212] hard stops on smart-contracts/upgrading/index --- .../ga/developers/docs/smart-contracts/upgrading/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/translations/ga/developers/docs/smart-contracts/upgrading/index.md b/public/content/translations/ga/developers/docs/smart-contracts/upgrading/index.md index d98d43acd13..4fd0c247399 100644 --- a/public/content/translations/ga/developers/docs/smart-contracts/upgrading/index.md +++ b/public/content/translations/ga/developers/docs/smart-contracts/upgrading/index.md @@ -22,7 +22,7 @@ Ní féidir leat clár a imscartar chuig seoladh ar líonra Ethereum a athrú go Is féidir é seo a dhéanamh trí na modhanna seo a leanas: -1. Leaganacha iolracha de chonradh cliste a chruthú agus staid ascnaimh (i.e. sonraí) ón seanchonradh go dtí ásc nua den chonradh. +1. Leaganacha iolracha de chonradh cliste a chruthú agus staid ascnaimh (i.e., sonraí) ón seanchonradh go dtí ásc nua den chonradh. 2. Conarthaí ar leith a chruthú chun loighic agus staid ghnó a stóráil. @@ -74,7 +74,7 @@ Teastaíonn tuiscint ar fheidhm **glaoch toscaire** chun na patrúin seachfhreas Ón [Doiciméadú Solidity](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries): -> _Tá leagan speisialta de ghlao teachtaireachta ann, darb ainm **glao toscaire** atá comhionann le glao teachtaireachta seachas an cód ag an sprioc-seoladh a dhéantar i gcomhthéacs (i.e. ag an seoladh) den chonradh glaonna agus `msg.sender` agus `msg.value` ná a luachanna a athrú._ _ Ciallaíonn sé seo gur féidir le conradh cód a lódáil go dinimiciúil ó sheoladh eile ag am rite. Tagraíonn stóras, seoladh reatha agus iarmhéid don chonradh atá ag glaoch, ní thógtar ach an cód ón seoladh a nglaoitear air._ +> _Tá leagan speisialta de ghlao teachtaireachta ann, darb ainm **glao toscaire** atá comhionann le glao teachtaireachta seachas an cód ag an sprioc-seoladh a dhéantar i gcomhthéacs (i.e., ag an seoladh) den chonradh glaonna agus `msg.sender` agus `msg.value` ná a luachanna a athrú._ _ Ciallaíonn sé seo gur féidir le conradh cód a lódáil go dinimiciúil ó sheoladh eile ag am rite. Tagraíonn stóras, seoladh reatha agus iarmhéid don chonradh atá ag glaoch, ní thógtar ach an cód ón seoladh a nglaoitear air._ Tá a fhios ag an gconradh seachfhreastalaí `glaochtoscaire` a agairt aon uair a ghlaonn úsáideoir ar fheidhm toisc go bhfuil feidhm `tacachumais` ionsuite ann. I ríomhchlárú Solidity déantar an [fheidhm tacachumais](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) nuair nach meaitseálann glao feidhme na feidhmeanna sonraithe i gconradh. @@ -94,7 +94,7 @@ Bíonn tionchar ag an [bpatrún straitéise](https://en.wikipedia.org/wiki/Strat Sa phríomhchonradh sa chás seo tá an loighic lárnach gnó, ach déanann sé comhéadan le conarthaí cliste eile ("conarthaí satailíte") chun feidhmeanna áirithe a rith. Stórálann an príomhchonradh seo seoladh gach conartha satailíte agus féadann sé aistriú idir feidhmeanna éagsúla an chonartha satailíte. -Is féidir leat conradh satailíte nua a thógáil agus an príomhchonradh a chumrú leis an seoladh nua. Ligeann sé seo duit _straitéisí_ a athrú (i.e. loighic nua a chur i bhfeidhm) le haghaidh conradh cliste. +Is féidir leat conradh satailíte nua a thógáil agus an príomhchonradh a chumrú leis an seoladh nua. Ligeann sé seo duit _straitéisí_ a athrú (i.e., loighic nua a chur i bhfeidhm) le haghaidh conradh cliste. Cé go bhfuil sé cosúil leis an bpatrún seachfhreastalaí a pléadh níos luaithe, tá patrún na straitéise difriúil toisc go bhfuil loighic an ghnó i seilbh an phríomhchonartha, a n-idirghníomhaíonn úsáideoirí leis. Trí úsáid a bhaint as an bpatrún seo tugtar an deis duit athruithe teoranta a thabhairt isteach ar chonradh cliste gan cur isteach ar an mbonneagar lárnach. From d77df0389da123c5e4f86197eb14672a73811284 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:24:44 -0500 Subject: [PATCH 088/212] hard stops on single-slot-finality/index --- public/content/roadmap/single-slot-finality/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/roadmap/single-slot-finality/index.md b/public/content/roadmap/single-slot-finality/index.md index 08f8cb636df..0f24eab6d6a 100644 --- a/public/content/roadmap/single-slot-finality/index.md +++ b/public/content/roadmap/single-slot-finality/index.md @@ -44,9 +44,9 @@ In this scheme, it is only possible for every validator to vote on a block by di Since the Ethereum consensus mechanism was designed, the signature aggregation scheme (BLS) has been found to be far more scalable than was initially thought, while the ability of clients to process and verify signatures has also improved. It turns out that processing attestations from a huge number of validators is actually possible within a single slot. For example, with one million validators each voting twice in each slot, and slot times adjusted to be 16 seconds, nodes would be required to verify signatures at a minimum rate of 125,000 aggregations per second in order to process all 1 million attestations within the slot. In reality, it takes a normal computer around 500 nanoseconds to do one signature verification, meaning 125,000 can be done in ~62.5 ms - far below the one second threshold. -Further efficiency gains could be made by creating supercommittees of e.g. 125,000 randomly selected validators per slot. Only these validators get to vote on a block and therefore only this subset of validators decide whether a block is finalized. Whether this is a good idea or not comes down to how expensive the community would prefer a successful attack on Ethereum to be. This is because instead of requiring 2/3 of the total staked ether, an attacker could finalize a dishonest block with 2/3 of the staked ether _in that supercommittee_. This is still an active area of research, but it seems plausible that for a validator set sufficiently large to require supercommittees in the first place, the cost of attacking one of those subcommittees will be extremely high (e.g. the ETH denominated cost of attack would be `2/3 * 125,000 * 32 = ~2.6 million ETH`). The cost of attack can be adjusted by increasing the size of the validator set (e.g. tune the validator size so the cost of attack is equal to 1 million ether, 4 million ether, 10 million ether, etc). [Preliminary polls](https://youtu.be/ojBgyFl6-v4?t=755) of the community seem to suggest that 1-2 million ether is an acceptable cost of attack, which implies ~65,536 - 97,152 validators per supercommittee. +Further efficiency gains could be made by creating supercommittees of e.g., 125,000 randomly selected validators per slot. Only these validators get to vote on a block and therefore only this subset of validators decide whether a block is finalized. Whether this is a good idea or not comes down to how expensive the community would prefer a successful attack on Ethereum to be. This is because instead of requiring 2/3 of the total staked ether, an attacker could finalize a dishonest block with 2/3 of the staked ether _in that supercommittee_. This is still an active area of research, but it seems plausible that for a validator set sufficiently large to require supercommittees in the first place, the cost of attacking one of those subcommittees will be extremely high (e.g., the ETH denominated cost of attack would be `2/3 * 125,000 * 32 = ~2.6 million ETH`). The cost of attack can be adjusted by increasing the size of the validator set (e.g., tune the validator size so the cost of attack is equal to 1 million ether, 4 million ether, 10 million ether, etc). [Preliminary polls](https://youtu.be/ojBgyFl6-v4?t=755) of the community seem to suggest that 1-2 million ether is an acceptable cost of attack, which implies ~65,536 - 97,152 validators per supercommittee. -However, verification is not the true bottleneck - it is signature aggregation that really challenges validator nodes. To scale signature aggregation will probably require increasing the number of validators in each subnet, increasing the number of subnets, or adding additional layers of aggregation (i.e. implement committees of committees). Part of the solution might be allowing specialized aggregators - similar to how block building and generating commitments for rollup data will be outsourced to specialized block builders under proposer-builder separation (PBS) and Danksharding. +However, verification is not the true bottleneck - it is signature aggregation that really challenges validator nodes. To scale signature aggregation will probably require increasing the number of validators in each subnet, increasing the number of subnets, or adding additional layers of aggregation (i.e., implement committees of committees). Part of the solution might be allowing specialized aggregators - similar to how block building and generating commitments for rollup data will be outsourced to specialized block builders under proposer-builder separation (PBS) and Danksharding. ## What is the role of the fork-choice rule in SSF? {#role-of-the-fork-choice-rule} @@ -54,7 +54,7 @@ Today's consensus mechanism relies on a tight coupling between the finality gadg ## Outstanding issues {#outstanding-issues} -The problem with scaling aggregation by growing the number of validators per subnet is that it leads to greater load on the peer-to-peer network. The problem with adding layers of aggregations is that it is quite complex to engineer and adds latency (i.e. it could take longer for the block proposer to hear from all the subnet aggregators). It is also not clear how to deal with the scenario that there are more active validators on the network than can feasibly be processed in each slot, even with BLS signature aggregation. One potential solution is that, because all validators attest in every slot and there are no committees under SSF, the 32 ETH cap on the effective balance could be removed entirely, meaning operators managing multiple validators could consolidate their stake and run fewer, reducing the number of messages that validating nodes have to process to account for the entire validator set. This relies on large stakers agreeing to consolidate their validators. It is also possible to impose a fixed cap on the number of validators or the amount of staked ETH at any time. However, this requires some mechanism for deciding which validators are allowed to participate and which are not, which is liable to create unwanted secondary effects. +The problem with scaling aggregation by growing the number of validators per subnet is that it leads to greater load on the peer-to-peer network. The problem with adding layers of aggregations is that it is quite complex to engineer and adds latency (i.e., it could take longer for the block proposer to hear from all the subnet aggregators). It is also not clear how to deal with the scenario that there are more active validators on the network than can feasibly be processed in each slot, even with BLS signature aggregation. One potential solution is that, because all validators attest in every slot and there are no committees under SSF, the 32 ETH cap on the effective balance could be removed entirely, meaning operators managing multiple validators could consolidate their stake and run fewer, reducing the number of messages that validating nodes have to process to account for the entire validator set. This relies on large stakers agreeing to consolidate their validators. It is also possible to impose a fixed cap on the number of validators or the amount of staked ETH at any time. However, this requires some mechanism for deciding which validators are allowed to participate and which are not, which is liable to create unwanted secondary effects. ## Current progress {#current-progress} From 19c6ac39b612ab877c7a888d09b7bacfd029fe33 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:25:12 -0500 Subject: [PATCH 089/212] hard stops on issuance/index --- public/content/roadmap/merge/issuance/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/roadmap/merge/issuance/index.md b/public/content/roadmap/merge/issuance/index.md index 6d2ef286172..663fcc22671 100644 --- a/public/content/roadmap/merge/issuance/index.md +++ b/public/content/roadmap/merge/issuance/index.md @@ -6,7 +6,7 @@ lang: en # How The Merge impacted ETH supply {#how-the-merge-impacts-ETH-supply} -The Merge represented the Ethereum network's transition from proof-of-work to proof-of-stake which occurred in September 2022. The way ETH was issued underwent changes at time of that transition. Previously, new ETH was issued from two sources: the execution layer (i.e. Mainnet) and the consensus layer (i.e. Beacon Chain). Since The Merge, issuance on the execution layer is now zero. Let's break this down. +The Merge represented the Ethereum network's transition from proof-of-work to proof-of-stake which occurred in September 2022. The way ETH was issued underwent changes at time of that transition. Previously, new ETH was issued from two sources: the execution layer (i.e., Mainnet) and the consensus layer (i.e., Beacon Chain). Since The Merge, issuance on the execution layer is now zero. Let's break this down. ## Components of ETH issuance {#components-of-eth-issuance} From d707496aeaffac0e11bc311c95435c5a052153a4 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:25:47 -0500 Subject: [PATCH 090/212] hard stops on merge/index --- public/content/roadmap/merge/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/roadmap/merge/index.md b/public/content/roadmap/merge/index.md index c277698b432..e0ecd438f04 100644 --- a/public/content/roadmap/merge/index.md +++ b/public/content/roadmap/merge/index.md @@ -118,13 +118,13 @@ The Merge also set the stage for further scalability upgrades not possible under +contentPreview="False. Anyone is free to sync their own self-verified copy of Ethereum (i.e., run a node). No ETH is required—not before The Merge, not after The Merge, not ever."> There are two types of Ethereum nodes: nodes that can propose blocks and nodes that don't. Nodes that propose blocks are only a small number of the total nodes on Ethereum. This category includes mining nodes under proof-of-work (PoW) and validator nodes under proof-of-stake (PoS). This category requires committing economic resources (such as GPU hash power in proof-of-work or staked ETH in proof-of-stake) in exchange for the ability to occasionally propose the next block and earn protocol rewards. -The other nodes on the network (i.e. the majority) are not required to commit any economic resources beyond a consumer-grade computer with 1-2 TB of available storage and an internet connection. These nodes do not propose blocks, but they still serve a critical role in securing the network by holding all block proposers accountable by listening for new blocks and verifying their validity on arrival according to the network consensus rules. If the block is valid, the node continues propagating it through the network. If the block is invalid for whatever reason, the node software will disregard it as invalid and stop its propagation. +The other nodes on the network (i.e., the majority) are not required to commit any economic resources beyond a consumer-grade computer with 1-2 TB of available storage and an internet connection. These nodes do not propose blocks, but they still serve a critical role in securing the network by holding all block proposers accountable by listening for new blocks and verifying their validity on arrival according to the network consensus rules. If the block is valid, the node continues propagating it through the network. If the block is invalid for whatever reason, the node software will disregard it as invalid and stop its propagation. Running a non-block-producing node is possible for anyone under either consensus mechanism (proof-of-work or proof-of-stake); it is strongly encouraged for all users if they have the means. Running a node is immensely valuable for Ethereum and gives added benefits to any individual running one, such as improved security, privacy and censorship resistance. @@ -149,7 +149,7 @@ title="Misconception: "Transactions were accelerated substantially by The M contentPreview="False. Though some slight changes exist, transaction speed is mostly the same on layer 1 now as it was before The Merge."> A transaction's "speed" can be measured in a few ways, including time to be included in a block and time to finalization. Both of these changes slightly, but not in a way that users will notice. -Historically, on proof-of-work, the target was to have a new block every ~13.3 seconds. Under proof-of-stake, slots occur precisely every 12 seconds, each of which is an opportunity for a validator to publish a block. Most slots have blocks, but not necessarily all (i.e. a validator is offline). In proof-of-stake, blocks are produced ~10% more frequently than on proof-of-work. This was a fairly insignificant change and is unlikely to be noticed by users. +Historically, on proof-of-work, the target was to have a new block every ~13.3 seconds. Under proof-of-stake, slots occur precisely every 12 seconds, each of which is an opportunity for a validator to publish a block. Most slots have blocks, but not necessarily all (i.e., a validator is offline). In proof-of-stake, blocks are produced ~10% more frequently than on proof-of-work. This was a fairly insignificant change and is unlikely to be noticed by users. Proof-of-stake introduced the transaction finality concept that did not previously exist. In proof-of-work, the ability to reverse a block gets exponentially more difficult with every passing block mined on top of a transaction, but it never quite reaches zero. Under proof-of-stake, blocks are bundled into epochs (6.4 minute spans of time containing 32 chances for blocks) which validators vote on. When an epoch ends, validators vote on whether to consider the epoch 'justified'. If validators agree to justify the epoch, it gets finalized in the next epoch. Undoing finalized transactions is economically inviable as it would require obtaining and burning over one-third of the total staked ETH. From 95a77e72c88501b7bd04d5f632b120eb01a4784d Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:28:28 -0500 Subject: [PATCH 091/212] hard stops on state-channels/index --- public/content/developers/docs/scaling/state-channels/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/scaling/state-channels/index.md b/public/content/developers/docs/scaling/state-channels/index.md index bb395088d8e..7050dd42339 100644 --- a/public/content/developers/docs/scaling/state-channels/index.md +++ b/public/content/developers/docs/scaling/state-channels/index.md @@ -31,7 +31,7 @@ A payment channel is best described as a "two-way ledger" collectively maintaine Updates to the ledger's balance (i.e., the payment channel's state) require the approval of all parties in the channel. A channel update, signed by all channel participants, is considered finalized, much like a transaction on Ethereum. -Payment channels were among the earliest scaling solutions designed to minimize expensive onchain activity of simple user interactions (e.g. ETH transfers, atomic swaps, micropayments). Channel participants can conduct an unlimited amount of instant, feeless transactions between each other as long as the net sum of their transfers does not exceed the deposited tokens. +Payment channels were among the earliest scaling solutions designed to minimize expensive onchain activity of simple user interactions (e.g., ETH transfers, atomic swaps, micropayments). Channel participants can conduct an unlimited amount of instant, feeless transactions between each other as long as the net sum of their transfers does not exceed the deposited tokens. ## State channels {#state-channels} From b2a3095cf398e69dfd0edaa345a0b47bb1f3ff49 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:30:49 -0500 Subject: [PATCH 092/212] hard stops on smart-contracts/anatomy/index --- .../content/developers/docs/smart-contracts/anatomy/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/docs/smart-contracts/anatomy/index.md b/public/content/developers/docs/smart-contracts/anatomy/index.md index 3b84d5d21cc..a8b40ed3786 100644 --- a/public/content/developers/docs/smart-contracts/anatomy/index.md +++ b/public/content/developers/docs/smart-contracts/anatomy/index.md @@ -76,9 +76,9 @@ In the most simplistic terms, functions can get information or set information i There are two types of function calls: - `internal` – these don't create an EVM call - - Internal functions and state variables can only be accessed internally (i.e. from within the current contract or contracts deriving from it) + - Internal functions and state variables can only be accessed internally (i.e., from within the current contract or contracts deriving from it) - `external` – these do create an EVM call - - External functions are part of the contract interface, which means they can be called from other contracts and via transactions. An external function `f` cannot be called internally (i.e. `f()` does not work, but `this.f()` works). + - External functions are part of the contract interface, which means they can be called from other contracts and via transactions. An external function `f` cannot be called internally (i.e., `f()` does not work, but `this.f()` works). They can also be `public` or `private` From f07c60ca161f5b89da10b2866db1961017098ce8 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:32:18 -0500 Subject: [PATCH 093/212] hard stops on smart-contracts/languages/index --- .../content/developers/docs/smart-contracts/languages/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/smart-contracts/languages/index.md b/public/content/developers/docs/smart-contracts/languages/index.md index 78725219c52..e947cbdb05e 100644 --- a/public/content/developers/docs/smart-contracts/languages/index.md +++ b/public/content/developers/docs/smart-contracts/languages/index.md @@ -180,7 +180,7 @@ def withdraw(): @external def endAuction(): # It is a good guideline to structure functions that interact - # with other contracts (i.e. they call functions or send ether) + # with other contracts (i.e., they call functions or send ether) # into three phases: # 1. checking conditions # 2. performing actions (potentially changing conditions) From c01dd816126cbd520a6e7019de3b2e740a907ad4 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:32:54 -0500 Subject: [PATCH 094/212] hard stops on danksharding/index --- public/content/roadmap/danksharding/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/roadmap/danksharding/index.md b/public/content/roadmap/danksharding/index.md index e22d76b31e3..1734ef9f6df 100644 --- a/public/content/roadmap/danksharding/index.md +++ b/public/content/roadmap/danksharding/index.md @@ -41,7 +41,7 @@ KZG stands for Kate-Zaverucha-Goldberg - the names of the three [original author ### What was the KZG Ceremony? {#what-is-a-kzg-ceremony} -The KZG ceremony was a way for many people from across the Ethereum community to collectively generate a secret random string of numbers that can be used to verify some data. It is very important that this string of numbers is not known and cannot be recreated by anyone. To ensure this, each person that participated in the ceremony received a string from the previous participant. They then created some new random values (e.g. by allowing their browser to measure the movement of their mouse) and mix it in with the previous value. They then sent the value on to the next participant and destroyed it from their local machine. As long as one person in the ceremony did this honestly, the final value will be unknowable to an attacker. +The KZG ceremony was a way for many people from across the Ethereum community to collectively generate a secret random string of numbers that can be used to verify some data. It is very important that this string of numbers is not known and cannot be recreated by anyone. To ensure this, each person that participated in the ceremony received a string from the previous participant. They then created some new random values (e.g., by allowing their browser to measure the movement of their mouse) and mix it in with the previous value. They then sent the value on to the next participant and destroyed it from their local machine. As long as one person in the ceremony did this honestly, the final value will be unknowable to an attacker. The EIP-4844 KZG ceremony was open to the public and tens of thousands of people participated to add their own entropy (randomness). In total there were over 140,000 contributions, making it the world's largest ceremony of its kind. For the ceremony to be undermined, 100% of those participants would have to be actively dishonest. From the perspective of the participants, if they know they were honest, there is no need to trust anyone else because they know that they secured the ceremony (they individually satisfied the 1-out-of-N honest participant requirement). @@ -53,7 +53,7 @@ When a rollup posts data in a blob, they provide a "commitment" that they post o -If someone knows the random locations used for the commitment, it is easy for them to generate a new polynomial that fits at those specific points (i.e. a "collision"). This means they could add or remove data from the blob and still provide a valid proof. To prevent this, instead of giving provers the actual secret locations, they actually receive the locations wrapped in a cryptographic "black box" using elliptic curves. These effectively scramble the values in such a way that the original values cannot be reverse-engineered, but with some clever algebra provers and verifiers can still evaluate polynomials at the points they represent. +If someone knows the random locations used for the commitment, it is easy for them to generate a new polynomial that fits at those specific points (i.e., a "collision"). This means they could add or remove data from the blob and still provide a valid proof. To prevent this, instead of giving provers the actual secret locations, they actually receive the locations wrapped in a cryptographic "black box" using elliptic curves. These effectively scramble the values in such a way that the original values cannot be reverse-engineered, but with some clever algebra provers and verifiers can still evaluate polynomials at the points they represent. From 086c8c0e3419a02cad6d82f37b484885641943a4 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:33:16 -0500 Subject: [PATCH 095/212] hard stops on how-to-use-a-bridge/index --- public/content/guides/how-to-use-a-bridge/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/guides/how-to-use-a-bridge/index.md b/public/content/guides/how-to-use-a-bridge/index.md index eaecafab031..5a0fede0a35 100644 --- a/public/content/guides/how-to-use-a-bridge/index.md +++ b/public/content/guides/how-to-use-a-bridge/index.md @@ -6,7 +6,7 @@ lang: en # How to bridge tokens to layer 2 -If there is a lot of traffic on Ethereum, it can become expensive. One solution to this is to create new "layers": i.e. different networks which operate in similar ways to Ethereum itself. These so-called Layer 2s help reduce congestion and cost on Ethereum by processing many more transactions at lower fees, and only storing the result of these on Ethereum every so often. As such, these layers 2s enable us to transact with increased speed and decreased costs. Many popular crypto projects are moving to layer 2s because of these benefits. The simplest way to move tokens from Ethereum to layer 2 is to use a bridge. +If there is a lot of traffic on Ethereum, it can become expensive. One solution to this is to create new "layers": i.e., different networks which operate in similar ways to Ethereum itself. These so-called Layer 2s help reduce congestion and cost on Ethereum by processing many more transactions at lower fees, and only storing the result of these on Ethereum every so often. As such, these layers 2s enable us to transact with increased speed and decreased costs. Many popular crypto projects are moving to layer 2s because of these benefits. The simplest way to move tokens from Ethereum to layer 2 is to use a bridge. **Prerequisite:** From 73e59f4831b176d9a2138aef70b98ceff69d8f3b Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:33:44 -0500 Subject: [PATCH 096/212] hard stops on how-to-create-an-ethereum-account/index --- .../content/guides/how-to-create-an-ethereum-account/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/guides/how-to-create-an-ethereum-account/index.md b/public/content/guides/how-to-create-an-ethereum-account/index.md index 8b371f21e67..8d3b7005a54 100644 --- a/public/content/guides/how-to-create-an-ethereum-account/index.md +++ b/public/content/guides/how-to-create-an-ethereum-account/index.md @@ -58,7 +58,7 @@ No. The wallet is a management tool that helps you to manage accounts. A single ### Can I send bitcoin to an Ethereum address, or ether to a Bitcoin address? -No, you cannot. Bitcoin and ether exist on two separate networks (i.e. different blockchains), each with their own bookkeeping and address formats. There have been various attempts to bridge the two different networks, of which the most active one is currently [Wrapped Bitcoin or WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/). This is not an endorsement, as WBTC is a custodial solution (meaning a single group of people controls certain critical functions) and is provided here for informational purposes only. +No, you cannot. Bitcoin and ether exist on two separate networks (i.e., different blockchains), each with their own bookkeeping and address formats. There have been various attempts to bridge the two different networks, of which the most active one is currently [Wrapped Bitcoin or WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/). This is not an endorsement, as WBTC is a custodial solution (meaning a single group of people controls certain critical functions) and is provided here for informational purposes only. ### If I own an ETH address, do I own the same address on other blockchains? From ec4deb42f6af0bb4660686eab8b7f1005fdc596b Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:35:00 -0500 Subject: [PATCH 097/212] hard stops on yellow-paper-evm/index --- public/content/developers/tutorials/yellow-paper-evm/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/tutorials/yellow-paper-evm/index.md b/public/content/developers/tutorials/yellow-paper-evm/index.md index 31370595026..64df6c93308 100644 --- a/public/content/developers/tutorials/yellow-paper-evm/index.md +++ b/public/content/developers/tutorials/yellow-paper-evm/index.md @@ -34,7 +34,7 @@ This section gives the basics of the EVM and how it compares with other computat A [stack machine](https://en.wikipedia.org/wiki/Stack_machine) is a computer that stores intermediate data not in registers, but in a [**stack**](). This is the preferred architecture for virtual machines because it is easy to implement meaning that bugs, and security vulnerabilities, are a lot less likely. The memory in the stack is divided into 256-bit words. This was chosen because it is convenient for Ethereum's core cryptographic operations such as Keccak-256 hashing and elliptic curve computations. The maximum size of the stack is 1024 items (1024 x 256 bits). When opcodes are executed they are usually getting their parameters from the stack. There are opcodes specifically for reorganizing elements in the stack such as `POP` (removes item from top of stack), `DUP_N` (duplicated N'th item in stack), etc. -The EVM also has a volatile space called **memory** which is used to store data during execution. This memory is organized into 32-byte words. All memory locations are initialized to zero. If you execute this [Yul](https://docs.soliditylang.org/en/latest/yul.html) code to add a word to memory, it will fill 32 bytes of memory by padding the empty space in the word with zeros, i.e. it creates one word - with zeros in locations 0-29, 0x60 to 30, and 0xA7 to 31. +The EVM also has a volatile space called **memory** which is used to store data during execution. This memory is organized into 32-byte words. All memory locations are initialized to zero. If you execute this [Yul](https://docs.soliditylang.org/en/latest/yul.html) code to add a word to memory, it will fill 32 bytes of memory by padding the empty space in the word with zeros, i.e., it creates one word - with zeros in locations 0-29, 0x60 to 30, and 0xA7 to 31. ```yul mstore(0, 0x60A7) From d880badf28aea12ead56cda91d8cedbb901de9ab Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:36:35 -0500 Subject: [PATCH 098/212] hard stops on nft-minter/index --- public/content/developers/tutorials/nft-minter/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/developers/tutorials/nft-minter/index.md b/public/content/developers/tutorials/nft-minter/index.md index 293d1edb685..51a81e15bdf 100644 --- a/public/content/developers/tutorials/nft-minter/index.md +++ b/public/content/developers/tutorials/nft-minter/index.md @@ -157,19 +157,19 @@ return (

🖼 Link to asset:

setURL(event.target.value)} />

🤔 Name:

setName(event.target.value)} />

✍️ Description:

setDescription(event.target.value)} /> @@ -439,7 +439,7 @@ function addWalletListener() { Let's quickly break down what's happening here: -- First, our function checks if `window.ethereum` is enabled \(i.e. MetaMask is installed\). +- First, our function checks if `window.ethereum` is enabled \(i.e., MetaMask is installed\). - If it's not, we simply set our `status` state variable to a JSX string that prompts the user to install MetaMask. - If it is enabled, we set up the listener `window.ethereum.on("accountsChanged")` on line 3 that listens for state changes in the MetaMask wallet, which include when the user connects an additional account to the dapp, switches accounts, or disconnects an account. If there is at least one account connected, the `walletAddress` state variable is updated as the first account in the `accounts` array returned by the listener. Otherwise, `walletAddress` is set as an empty string. From 9920daf3c90f9b2b9061e64557ab90e730b5a414 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:37:14 -0500 Subject: [PATCH 099/212] hard stops on how-to-use-echidna-to-test-smart-contracts/index --- .../how-to-use-echidna-to-test-smart-contracts/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md b/public/content/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md index 808fee7f921..d3007c033ac 100644 --- a/public/content/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md +++ b/public/content/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/index.md @@ -95,7 +95,7 @@ Echidna will: - Automatically generate arbitrary transactions to test the property. - Report any transactions leading a property to return `false` or throw an error. -- Discard side-effect when calling a property (i.e. if the property changes a state variable, it is discarded after the test) +- Discard side-effect when calling a property (i.e., if the property changes a state variable, it is discarded after the test) The following property checks that the caller has no more than 1000 tokens: From f264550a5b52df76520c7fca6a860d8889a8cd5e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:37:59 -0500 Subject: [PATCH 100/212] hard stops on hello-world-smart-contract-fullstack/index --- .../hello-world-smart-contract-fullstack/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/developers/tutorials/hello-world-smart-contract-fullstack/index.md b/public/content/developers/tutorials/hello-world-smart-contract-fullstack/index.md index b636638c7dd..3196f587651 100644 --- a/public/content/developers/tutorials/hello-world-smart-contract-fullstack/index.md +++ b/public/content/developers/tutorials/hello-world-smart-contract-fullstack/index.md @@ -840,7 +840,7 @@ return ( If you scan this code carefully, you'll notice where we use our various state variables in our UI: -- On lines 6-12, if the user's wallet is connected \(i.e. `walletAddress.length > 0`\), we display a truncated version of the user `walletAddress` in the button with ID "walletButton;" otherwise it simply says "Connect Wallet." +- On lines 6-12, if the user's wallet is connected \(i.e., `walletAddress.length > 0`\), we display a truncated version of the user `walletAddress` in the button with ID "walletButton;" otherwise it simply says "Connect Wallet." - On line 17, we display the current message stored in the smart contract, which is captured in the `message` string. - On lines 23-26, we use a [controlled component](https://reactjs.org/docs/forms.html#controlled-components) to update our `newMessage` state variable when the input in the text field changes. @@ -1068,7 +1068,7 @@ contract HelloWorld { } ``` -Smart contract events are a way for your contract to communicate that something happened \(i.e. there was an _event_\) on the blockchain to your front-end application, which can be 'listening' for specific events and take action when they happen. +Smart contract events are a way for your contract to communicate that something happened \(i.e., there was an _event_\) on the blockchain to your front-end application, which can be 'listening' for specific events and take action when they happen. The `addSmartContractListener` function is going to specifically listen for our Hello World smart contract's `UpdatedMessages` event, and update our UI to display the new message. @@ -1343,7 +1343,7 @@ function addWalletListener() { I bet you don't even need our help to understand what's going on here at this point, but for thoroughness purposes, let's quickly break it down: -- First, our function checks if `window.ethereum` is enabled \(i.e. MetaMask is installed\). +- First, our function checks if `window.ethereum` is enabled \(i.e., MetaMask is installed\). - If it's not, we simply set our `status` state variable to a JSX string that prompts the user to install MetaMask. - If it is enabled, we set up the listener `window.ethereum.on("accountsChanged")` on line 3 that listens for state changes in the MetaMask wallet, which include when the user connects an additional account to the dapp, switches accounts, or disconnects an account. If there is at least one account connected, the `walletAddress` state variable is updated as the first account in the `accounts` array returned by the listener. Otherwise, `walletAddress` is set as an empty string. @@ -1381,7 +1381,7 @@ This won't take very long; let's finish this dapp! Naturally, it makes sense to have some sort of input error handling at the start of the function. -We'll want our function to return early if there is no MetaMask extension installed, there is no wallet connected \(i.e. the `address` passed in is an empty string\), or the `message` is an empty string. Let's add the following error handling to `updateMessage`: +We'll want our function to return early if there is no MetaMask extension installed, there is no wallet connected \(i.e., the `address` passed in is an empty string\), or the `message` is an empty string. Let's add the following error handling to `updateMessage`: ```javascript // interact.js From 186645159db023f8cd14655887c45c0e96e57379 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:38:46 -0500 Subject: [PATCH 101/212] hard stops on guide-to-smart-contract-security-tools/index --- .../guide-to-smart-contract-security-tools/index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/public/content/developers/tutorials/guide-to-smart-contract-security-tools/index.md b/public/content/developers/tutorials/guide-to-smart-contract-security-tools/index.md index fd5fa1255c0..46c16483520 100644 --- a/public/content/developers/tutorials/guide-to-smart-contract-security-tools/index.md +++ b/public/content/developers/tutorials/guide-to-smart-contract-security-tools/index.md @@ -12,7 +12,7 @@ sourceUrl: https://github.com/crytic/building-secure-contracts/tree/master/progr We are going to use three distinctive testing and program analysis techniques: -- **Static analysis with [Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/).** All the paths of the program are approximated and analyzed at the same time, through different program presentations (e.g. control-flow-graph) +- **Static analysis with [Slither](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/).** All the paths of the program are approximated and analyzed at the same time, through different program presentations (e.g., control-flow-graph) - **Fuzzing with [Echidna](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/).** The code is executed with a pseudo-random generation of transactions. The fuzzer will try to find a sequence of transactions to violate a given property. - **Symbolic execution with [Manticore](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/).** A formal verification technique, which translates each execution path to a mathematical formula, on which on top constraints can be checked. @@ -26,7 +26,7 @@ Each technique has advantages and pitfalls, and will be useful in [specific case \* if all the paths are explored without timeout -**Slither** analyzes contracts within seconds, however, static analysis might lead to false alarms and will be less suitable for complex checks (e.g. arithmetic checks). Run Slither via the API for push-button access to built-in detectors or via the API for user-defined checks. +**Slither** analyzes contracts within seconds, however, static analysis might lead to false alarms and will be less suitable for complex checks (e.g., arithmetic checks). Run Slither via the API for push-button access to built-in detectors or via the API for user-defined checks. **Echidna** needs to run for several minutes and will only produce true positives. Echidna checks user-provided security properties, written in Solidity. It might miss bugs since it is based on random exploration. @@ -41,7 +41,7 @@ Start with Slither's built-in detectors to ensure that no simple bugs are presen - Use Slither to write custom static checks - Use Manticore once you want in-depth assurance of critical security properties -**A note on unit tests**. Unit tests are necessary to build high-quality software. However, these techniques are not the best suited to find security flaws. They are typically used to test positive behaviors of code (i.e. the code works as expected in the normal context), while security flaws tend to reside in edge cases that the developers did not consider. In our study of dozens of smart contract security reviews, [unit test coverage had no effect on the number or severity of security flaws](https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/) we found in our client's code. +**A note on unit tests**. Unit tests are necessary to build high-quality software. However, these techniques are not the best suited to find security flaws. They are typically used to test positive behaviors of code (i.e., the code works as expected in the normal context), while security flaws tend to reside in edge cases that the developers did not consider. In our study of dozens of smart contract security reviews, [unit test coverage had no effect on the number or severity of security flaws](https://blog.trailofbits.com/2019/08/08/246-findings-from-our-smart-contract-audits-an-executive-summary/) we found in our client's code. ## Determining Security Properties {#determining-security-properties} @@ -64,7 +64,7 @@ The broad areas that are frequently relevant for smart contracts include: - Echidna and Manticore are the tools to favor to test state-machine specifications. -- **Access controls.** If your system has privileged users (e.g. an owner, controllers, ...) you must ensure that (1) each user can only perform the authorized actions and (2) no user can block actions from a more privileged user. +- **Access controls.** If your system has privileged users (e.g., an owner, controllers, ...) you must ensure that (1) each user can only perform the authorized actions and (2) no user can block actions from a more privileged user. - Slither, Echidna and Manticore can check for correct access controls. For example, Slither can check that only whitelisted functions lack the onlyOwner modifier. Echidna and Manticore are useful for more complex access control, such as a permission given only if the contract reaches a given state. @@ -80,7 +80,7 @@ The broad areas that are frequently relevant for smart contracts include: - Manticore and Echidna are the best choice for testing external interactions with your contracts. Manticore has an built-in mechanism to stub external contracts. -- **Standard conformance.** Ethereum standards (e.g. ERC20) have a history of flaws in their design. Be aware of the limitations of the standard you are building on. +- **Standard conformance.** Ethereum standards (e.g., ERC20) have a history of flaws in their design. Be aware of the limitations of the standard you are building on. - Slither, Echidna, and Manticore will help you to detect deviations from a given standard. ### Tool selection cheatsheet {#tool-selection-cheatsheet} From 5b1f6e762b581b0d28f0f9b3aa599ae902f52e9b Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:39:29 -0500 Subject: [PATCH 102/212] hard stops on eip-1271-smart-contract-signatures/index --- .../tutorials/eip-1271-smart-contract-signatures/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/developers/tutorials/eip-1271-smart-contract-signatures/index.md b/public/content/developers/tutorials/eip-1271-smart-contract-signatures/index.md index 5c60937ad63..3a3b2412f8f 100644 --- a/public/content/developers/tutorials/eip-1271-smart-contract-signatures/index.md +++ b/public/content/developers/tutorials/eip-1271-smart-contract-signatures/index.md @@ -32,7 +32,7 @@ In the same way, a digital signature doesn’t mean anything without an associat In order to create a digital signature for use on Ethereum-based blockchains, you generally need a secret private key which no one else knows. This is what makes your signature, yours (no one else can create the same signature without knowledge of the secret key). -Your Ethereum account (i.e. your externally-owned account/EOA) has a private key associated with it, and this is the private key that’s typically used when a website or dapp asks you for a signature (e.g. for “Log in with Ethereum”). +Your Ethereum account (i.e., your externally-owned account/EOA) has a private key associated with it, and this is the private key that’s typically used when a website or dapp asks you for a signature (e.g., for “Log in with Ethereum”). An app can [verify a signature](https://docs.alchemy.com/docs/how-to-verify-a-message-signature-on-ethereum) you create using a third-party library like ethers.js [without knowing your private key](https://en.wikipedia.org/wiki/Public-key_cryptography) and be confident that _you_ were the one that created the signature. @@ -94,7 +94,7 @@ In Safe’s code, `isValidSignature` [is implemented](https://github.com/safe-gl 1. Onchain messages 1. Creation: a safe owner creates a new safe transaction to “sign” a message, passing the message as data into the transaction. Once enough owners sign the transaction to reach the multisig threshold, the transaction is broadcast and run. In the transaction, there is a safe function called which adds the message to a list of “approved” messages. - 2. Verification: call `isValidSignature` on the Safe contract, and pass in the message to verify as the message parameter and [an empty value for the signature parameter](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (i.e. `0x`). The Safe will see that the signature parameter is empty and instead of cryptographically verifying the signature, it will know to just go ahead and check whether the message is on the list of “approved” messages. + 2. Verification: call `isValidSignature` on the Safe contract, and pass in the message to verify as the message parameter and [an empty value for the signature parameter](https://github.com/safe-global/safe-contracts/blob/main/contracts/handler/CompatibilityFallbackHandler.sol#L32) (i.e., `0x`). The Safe will see that the signature parameter is empty and instead of cryptographically verifying the signature, it will know to just go ahead and check whether the message is on the list of “approved” messages. 2. Offchain messages: 1. Creation: a safe owner creates a message offchain, then gets other safe owners to sign the message each individually until there are enough signatures to overcome the multisig approval threshold. 2. Verification: call `isValidSignature`. In the message parameter, pass in the message to be verified. In the signature parameter, pass in each safe owner’s individual signatures all concatenated together, back-to-back. The Safe will check that there are enough signatures to meet the threshold **and** that each signature is valid. If so, it will return a value indicating successful signature verification. @@ -103,7 +103,7 @@ In Safe’s code, `isValidSignature` [is implemented](https://github.com/safe-gl You might have noticed that the `isValidSignature` function in the [EIP-1271 interface](https://eips.ethereum.org/EIPS/eip-1271) doesn’t take in the message itself, but instead a `_hash` parameter. What this means is that instead of passing the full arbitrary-length message to `isValidSignature`, we instead pass a 32-byte hash of the message (generally keccak256). -Each byte of calldata — i.e. function parameter data passed to a smart contract function — [costs 16 gas (4 gas if zero byte)](https://eips.ethereum.org/EIPS/eip-2028), so this can save a lot of gas if a message is long. +Each byte of calldata — i.e., function parameter data passed to a smart contract function — [costs 16 gas (4 gas if zero byte)](https://eips.ethereum.org/EIPS/eip-2028), so this can save a lot of gas if a message is long. ### Previous EIP-1271 Specifications From 44da09caa21cce6f75d465f157b39c1ec9e02cc1 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:41:25 -0500 Subject: [PATCH 103/212] hard stops on transactions/index --- public/content/developers/docs/transactions/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/transactions/index.md b/public/content/developers/docs/transactions/index.md index b526ba072e3..34d6b51c3e3 100644 --- a/public/content/developers/docs/transactions/index.md +++ b/public/content/developers/docs/transactions/index.md @@ -172,7 +172,7 @@ Gas is required for any transaction that involves a smart contract. Smart contracts can also contain functions known as [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) or [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions) functions, which do not alter the state of the contract. As such, calling these functions from an EOA will not require any gas. The underlying RPC call for this scenario is [`eth_call`](/developers/docs/apis/json-rpc#eth_call). -Unlike when accessed using `eth_call`, these `view` or `pure` functions are also commonly called internally (i.e. from the contract itself or from another contract) which does cost gas. +Unlike when accessed using `eth_call`, these `view` or `pure` functions are also commonly called internally (i.e., from the contract itself or from another contract) which does cost gas. ## Transaction lifecycle {#transaction-lifecycle} From f89d4c962b4240893773f74f5b5a5c7d5efbe4c1 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:42:06 -0500 Subject: [PATCH 104/212] hard stops on smart-contracts/verifying/index --- .../developers/docs/smart-contracts/verifying/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/docs/smart-contracts/verifying/index.md b/public/content/developers/docs/smart-contracts/verifying/index.md index 99287323ff3..232dd0c04f7 100644 --- a/public/content/developers/docs/smart-contracts/verifying/index.md +++ b/public/content/developers/docs/smart-contracts/verifying/index.md @@ -6,7 +6,7 @@ lang: en [Smart contracts](/developers/docs/smart-contracts/) are designed to be “trustless”, meaning users shouldn’t have to trust third parties (e.g., developers and companies) before interacting with a contract. As a requisite for trustlessness, users and other developers must be able to verify a smart contract’s source code. Source code verification assures users and developers that the published contract code is the same code running at the contract address on the Ethereum blockchain. -It is important to make the distinction between "source code verification" and "[formal verification](/developers/docs/smart-contracts/formal-verification/)". Source code verification, which will be explained in detail below, refers to verifying that the given source code of a smart contract in a high-level language (e.g. Solidity) compiles to the same bytecode to be executed at the contract address. However, formal verification describes verifying the correctness of a smart contract, meaning the contract behaves as expected. Although context-dependent, contract verification usually refers to source code verification. +It is important to make the distinction between "source code verification" and "[formal verification](/developers/docs/smart-contracts/formal-verification/)". Source code verification, which will be explained in detail below, refers to verifying that the given source code of a smart contract in a high-level language (e.g., Solidity) compiles to the same bytecode to be executed at the contract address. However, formal verification describes verifying the correctness of a smart contract, meaning the contract behaves as expected. Although context-dependent, contract verification usually refers to source code verification. ## What is source code verification? {#what-is-source-code-verification} @@ -46,7 +46,7 @@ Publishing a smart contract's source code files makes it easier for those intere ## How to verify source code for Ethereum smart contracts {#source-code-verification-for-ethereum-smart-contracts} -[Deploying a smart contract on Ethereum](/developers/docs/smart-contracts/deploying/) requires sending a transaction with a data payload (compiled bytecode) to a special address. The data payload is generated by compiling the source code, plus the [constructor arguments](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) of the contract instance appended to the data payload in the transaction. Compilation is deterministic, meaning it always produces the same output (i.e., contract bytecode) if the same source files, and compilation settings (e.g. compiler version, optimizer) are used. +[Deploying a smart contract on Ethereum](/developers/docs/smart-contracts/deploying/) requires sending a transaction with a data payload (compiled bytecode) to a special address. The data payload is generated by compiling the source code, plus the [constructor arguments](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor) of the contract instance appended to the data payload in the transaction. Compilation is deterministic, meaning it always produces the same output (i.e., contract bytecode) if the same source files, and compilation settings (e.g., compiler version, optimizer) are used. ![A diagram showing showing smart contract source code verification](./source-code-verification.png) From 0d4a5302f2e46fba58b8843733c5edb135ecf65e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:42:44 -0500 Subject: [PATCH 105/212] hard stops on smart-contracts/upgrading/index --- .../content/developers/docs/smart-contracts/upgrading/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/smart-contracts/upgrading/index.md b/public/content/developers/docs/smart-contracts/upgrading/index.md index aa0c08a9df0..53559565be4 100644 --- a/public/content/developers/docs/smart-contracts/upgrading/index.md +++ b/public/content/developers/docs/smart-contracts/upgrading/index.md @@ -74,7 +74,7 @@ Using the proxy patterns requires an understanding of the **delegatecall** funct From the [Solidity documentation](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries): -> _There exists a special variant of a message call, named **delegatecall** which is identical to a message call apart from the fact that the code at the target address is executed in the context (i.e. at the address) of the calling contract and `msg.sender` and `msg.value` do not change their values._ _This means that a contract can dynamically load code from a different address at runtime. Storage, current address and balance still refer to the calling contract, only the code is taken from the called address._ +> _There exists a special variant of a message call, named **delegatecall** which is identical to a message call apart from the fact that the code at the target address is executed in the context (i.e., at the address) of the calling contract and `msg.sender` and `msg.value` do not change their values._ _This means that a contract can dynamically load code from a different address at runtime. Storage, current address and balance still refer to the calling contract, only the code is taken from the called address._ The proxy contract knows to invoke `delegatecall` whenever a user calls a function because it has a `fallback` function built into it. In Solidity programming the [fallback function](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) is executed when a function call does not match functions specified in a contract. From 4802328cd02208b2182703b377e72312bc47bc0b Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:48:52 -0500 Subject: [PATCH 106/212] hard stops on .env.example --- .env.example | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.env.example b/.env.example index ca0e328cbc8..4b2bf469066 100644 --- a/.env.example +++ b/.env.example @@ -1,7 +1,7 @@ # rename this file to .env and supply the values listed below -# also make sure they are available to the build tool (e.g. Netlify) +# also make sure they are available to the build tool (e.g., Netlify) # warning: variables prefixed with NEXT_PUBLIC_ will be made available to client-side code -# be careful not to expose sensitive data (e.g. your Algolia admin key) +# be careful not to expose sensitive data (e.g., your Algolia admin key) # Algolia environment (app ID, search key and base search index name required for search) # You can use the following test keys provided by DocSearch for local development/testing: @@ -35,12 +35,12 @@ NEXT_PUBLIC_MATOMO_SITE_ID= NEXT_PUBLIC_IS_PREVIEW_DEPLOY=false # Build pages only for the specified langs. Leave it empty to build all the langs -# e.g. `en,fr` will only build English and French pages +# e.g., `en,fr` will only build English and French pages # Note: always include `en` as it is the default lang of the site NEXT_PUBLIC_BUILD_LOCALES= # If resource constraints are being hit during builds, change LIMIT_CPUS to a -# fixed number of CPUs (e.g. 2) to limit the demand during build time +# fixed number of CPUs (e.g., 2) to limit the demand during build time LIMIT_CPUS= # Enables the bundle analyzer From c27d68947472fb1f0c58ad25407b82e838cbc540 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:49:35 -0500 Subject: [PATCH 107/212] hard stops on code_of_conduct --- CODE_OF_CONDUCT.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 6d6e6fbff71..2cec3d7cb01 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -62,7 +62,7 @@ Examples of unacceptable behavior by participants include: Violations of the code of conduct will normally be visible to the community as we try to do everything in open, public channels, allowing community members to self-police. -However, if something happens that you feel needs attention, you can raise it with someone who has a moderation role (e.g. discord guide) so that they can help investigate and execute the appropriate response. +However, if something happens that you feel needs attention, you can raise it with someone who has a moderation role (e.g., discord guide) so that they can help investigate and execute the appropriate response. When reporting, please include as much detail as possible, including specific examples and timestamps. This will help to ensure a fair outcome. From 940296eb340ae41f7e7b1acf7a0f7678a18caacb Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:50:11 -0500 Subject: [PATCH 108/212] hard stops on readme --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 4e4d7936c20..2cbdf908491 100644 --- a/README.md +++ b/README.md @@ -133,7 +133,7 @@ pnpm dev - Open this directory in your favorite text editor / IDE, and see your changes live by visiting `localhost:3000` from your browser - Pro Tip: - Explore scripts within `package.json` for more build options - - Get **faster** production builds by building only one language. E.g. in your `.env` file, set `NEXT_PUBLIC_BUILD_LOCALES=en` to build the content only in English + - Get **faster** production builds by building only one language, e.g., in your `.env` file, set `NEXT_PUBLIC_BUILD_LOCALES=en` to build the content only in English - To build the site in other selected languages too, you need to set them in `NEXT_PUBLIC_BUILD_LOCALES`, eg: `NEXT_PUBLIC_BUILD_LOCALES=en,es` if you also want to build only English (required) and Spanish. - To build all languages, simply comment this line out with a hash mark, eg: `# NEXT_PUBLIC_BUILD_LOCALES=` @@ -156,7 +156,7 @@ git push - After your changes are committed to your GitHub fork, submit a pull request (PR) to the `dev` branch of the `ethereum/ethereum-org-website` repo - In your PR description, reference the issue it resolves (see [linking a pull request to an issue using a keyword](https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)) - ex. `Updates out of date content [Fixes #1234]` -- Netlify (our hosting service for build previews) deploys all PRs to a publicly accessible preview URL, e.g.: ![Netlify deploy preview](public/images/preview-deploy.png) +- Netlify (our hosting service for build previews) deploys all PRs to a publicly accessible preview URL, e.g.,: ![Netlify deploy preview](public/images/preview-deploy.png) - _Confirm that your Netlify preview deploy looks and functions as expected_ - Why not say hi and draw attention to your PR in [our discord server](https://discord.gg/ethereum-org)? From 79113c90a28dc18edaef16d4d69ad65ceae43ac9 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:51:23 -0500 Subject: [PATCH 109/212] hard stops on suggest_wallet.yaml --- .github/ISSUE_TEMPLATE/suggest_wallet.yaml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/suggest_wallet.yaml b/.github/ISSUE_TEMPLATE/suggest_wallet.yaml index 1f356b336e1..892c22d5781 100644 --- a/.github/ISSUE_TEMPLATE/suggest_wallet.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_wallet.yaml @@ -55,7 +55,7 @@ body: id: wallet_url attributes: label: URL to the project - description: Please provide a URL (e.g. to the website of the wallet). + description: Please provide a URL (e.g., to the website of the wallet). validations: required: true - type: input @@ -129,7 +129,7 @@ body: id: wallets_hardware attributes: label: Is it a hardware wallet? - description: How does it broadcast signed transactions (e.g. USB, Bluetooth, QR code)? + description: How does it broadcast signed transactions (e.g., USB, Bluetooth, QR code)? validations: required: true - type: markdown @@ -194,7 +194,7 @@ body: id: wallet_scam_protection attributes: label: Scam protection? - description: Does the wallet employ any practices to warn users against potential scams (e.g. when interacting with suspicious accounts/contracts)? + description: Does the wallet employ any practices to warn users against potential scams (e.g., when interacting with suspicious accounts/contracts)? validations: required: true - type: markdown @@ -205,7 +205,7 @@ body: id: wallet_dapp_support attributes: label: Does the wallet support connecting to Ethereum applications? - description: Please provide documentation for how users connect to applications. List examples (ie. WalletConnect, connect wallet to dapp directly, in wallet browser, etc.) + description: Please provide documentation for how users connect to applications. List examples (i.e., WalletConnect, connect wallet to dapp directly, in wallet browser, etc.) validations: required: true - type: dropdown @@ -379,7 +379,7 @@ body: id: wallet_extra attributes: label: Does the wallet have any integrated tools not mentioned above? - description: Please provide any information about extra features this wallet has that we may have missed in the above criteria. (e.g. privacy features, transaction batching, etc). + description: Please provide any information about extra features this wallet has that we may have missed in the above criteria. (e.g., privacy features, transaction batching, etc). - type: checkboxes id: wallet_work_on attributes: From f51bb2c3032ec9eecf5c077df1b79d875b957c85 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:51:58 -0500 Subject: [PATCH 110/212] hard stops on roadmap.tsx --- app/[locale]/roadmap/_components/roadmap.tsx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/app/[locale]/roadmap/_components/roadmap.tsx b/app/[locale]/roadmap/_components/roadmap.tsx index f8bb92e4624..9edb75c523c 100644 --- a/app/[locale]/roadmap/_components/roadmap.tsx +++ b/app/[locale]/roadmap/_components/roadmap.tsx @@ -264,7 +264,7 @@ const RoadmapPage = () => {

Some upgrades are lower priority and likely not to be - implemented for the next 5-10 years (e.g. quantum + implemented for the next 5-10 years (e.g., quantum resistance).{" "} Giving precise timing of each upgrade is complicated @@ -272,7 +272,7 @@ const RoadmapPage = () => { to predict as many roadmap items are worked on in parallel and developed at different speeds. The urgency of an upgrade can also change over time depending on external factors - (e.g. a sudden leap in the performance and availability of + (e.g., a sudden leap in the performance and availability of quantum computers may make quantum-resistant cryptography more urgent).

From bc80c875f2caa32c7225c879ff061129fba1dee1 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:52:40 -0500 Subject: [PATCH 111/212] hard stops on ds-implementation.md --- docs/ds-implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/ds-implementation.md b/docs/ds-implementation.md index 7684afd74e7..fff55c4a411 100644 --- a/docs/ds-implementation.md +++ b/docs/ds-implementation.md @@ -31,7 +31,7 @@ If you are implementing: - Try to avoid creating a new component file `/ComponentA/index.tsx` if there is no additional or custom logic we need to add to them - Create a theme file to override the default Chakra styles with the DS specs. See examples under the [Chakra theme folder](https://github.com/ethereum/ethereum-org-website/tree/dev/src/%40chakra-ui/components) - Create a `.stories.tsx` file under `src/components/BaseStories` -- A new custom component (e.g. the PageHero) +- A new custom component (e.g., the PageHero) - Use as many Chakra components as possible - Avoid implementing previous implementation details or styles if Chakra offers a solution for that From 55e58e847e3c8954c1f77b3a8c3c5daffe0b5870 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:53:03 -0500 Subject: [PATCH 112/212] hard stops on event-tracking.md --- docs/event-tracking.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/event-tracking.md b/docs/event-tracking.md index 0b35528cce3..34713b3c13b 100644 --- a/docs/event-tracking.md +++ b/docs/event-tracking.md @@ -35,7 +35,7 @@ It's helpful to ask yourself how the results of what we track and measure might # How to name events? -Broadly, events should be grouped by specific topic (e.g. L2 page external links, selected bridge, selected cex). +Broadly, events should be grouped by specific topic (e.g., L2 page external links, selected bridge, selected cex). ## Each event comprises 4 hierarchical values: From 6970060e30684b4ad5459ebce42c16b7a119ab0c Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:53:51 -0500 Subject: [PATCH 113/212] hard stops on markdownChecker.ts --- src/scripts/markdownChecker.ts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/scripts/markdownChecker.ts b/src/scripts/markdownChecker.ts index 2c64a4f739d..01b45a6e069 100644 --- a/src/scripts/markdownChecker.ts +++ b/src/scripts/markdownChecker.ts @@ -70,7 +70,7 @@ const SPELLING_MISTAKES: Array = [ // ! Current usage of this const is commented out // const CASE_SENSITIVE_SPELLING_MISTAKES = ["Thereum", "Metamask", "Github"] // Ideas: -// Regex for explicit lang path (e.g. /en/) && for glossary links (trailing slash breaks links e.g. /glossary/#pos/ doesn't work) +// Regex for explicit lang path (e.g., /en/) && for glossary links (trailing slash breaks links e.g., /glossary/#pos/ doesn't work) // We should have case sensitive spelling mistakes && check they are not in links. interface Languages { @@ -119,7 +119,7 @@ function sortMarkdownPathsIntoLanguages( const isTranslation = path.includes(translationDir) const langIndex = path.indexOf(translationDir) + translationDir.length - // RegEx to grab the root of the path (e.g. the lang code for translated files) + // RegEx to grab the root of the path (e.g., the lang code for translated files) const regex = /^([^/]+)\// const match = path.substring(langIndex).match(regex) const lang = isTranslation && match && match.length > 1 ? match[1] : "en" From 02b2fc9d47138134370d9a06b8caa470bb9cf131 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:55:34 -0500 Subject: [PATCH 114/212] hard stops on page-trillion-dollar-security.json --- src/intl/en/page-trillion-dollar-security.json | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/intl/en/page-trillion-dollar-security.json b/src/intl/en/page-trillion-dollar-security.json index c9c8235fcd0..87d3cc95b8a 100644 --- a/src/intl/en/page-trillion-dollar-security.json +++ b/src/intl/en/page-trillion-dollar-security.json @@ -42,7 +42,7 @@ "page-trillion-dollar-security-section-1-1-paragraph-2": "Most widely used software wallets rely on users securely storing seed phrases representing their underlying cryptographic private key, which often leads them to use insecure workarounds like storing seed phrases in plaintext, on cloud services, or writing them down on paper.", "page-trillion-dollar-security-section-1-1-paragraph-3": "Hardware wallets are an alternative, which enable users to manage a cryptographic key stored within a special purpose physical device. However, hardware wallets have their own flaws and attack surface. Hardware wallets can be lost, damaged, or stolen. Many hardware wallets are not open source and may have opaque supply chains, raising the risk of a supply chain attack where compromised devices are sold into the market.", "page-trillion-dollar-security-section-1-1-paragraph-4": "Whether keys are managed in a software or hardware wallet, many users are understandably nervous about self custody when it can be compromised through physical theft or assault.", - "page-trillion-dollar-security-section-1-1-paragraph-5": "Enterprise and institutional users face additional challenges in key management. If individual employees hold keys (e.g. as part of a multisig wallet), the organization must be able to replace them and create new ones due to personnel changes over time. Compliance requirements in different industries and jurisdictions may require custom workflows or audit trails not supported by existing wallet software. In some cases, enterprise users turn to third-party custodians for digital assets, which may introduce another layer of security risks to consider.", + "page-trillion-dollar-security-section-1-1-paragraph-5": "Enterprise and institutional users face additional challenges in key management. If individual employees hold keys (e.g., as part of a multisig wallet), the organization must be able to replace them and create new ones due to personnel changes over time. Compliance requirements in different industries and jurisdictions may require custom workflows or audit trails not supported by existing wallet software. In some cases, enterprise users turn to third-party custodians for digital assets, which may introduce another layer of security risks to consider.", "page-trillion-dollar-security-section-1-2-title": "1.2 Blind signing & transaction uncertainty", "page-trillion-dollar-security-section-1-2-paragraph": "Users routinely approve transactions \"blindly\" without understanding what they are doing. Wallets often present raw hexadecimal data, truncated contract address, or other information that is not sufficient for the user to understand the consequences of a given transaction. This leaves users of all kinds vulnerable to malicious smart contracts, phishing, scams, spoofed interfaces, front-end compromises, and basic user errors.", "page-trillion-dollar-security-section-1-3-title": "1.3 Approval and permission management", @@ -99,7 +99,7 @@ "page-trillion-dollar-security-section-2-2-list-title-4": "Low adoption of formal verification methods", "page-trillion-dollar-security-section-2-2-list-desc-4": "Formal verification techniques are powerful, but they are complex, costly, require specialized domain expertise, and are not well integrated into standard developer workflows, where they could be used much earlier in the production of software to verify safety at the specification stage.", "page-trillion-dollar-security-section-2-2-list-title-5": "Issues related to contract verification", - "page-trillion-dollar-security-section-2-2-list-desc-5": "Users and developers cannot easily assess the trustworthiness of deployed contracts, the extent of their security validation (e.g. code audits), or the presence of latent risks. While solutions exist for this purpose, many issues remain. Tooling that addresses these issues is not widely adopted, the standards that would unify the approaches remain fragmented, and some of the existing services are themselves centralized dependencies.", + "page-trillion-dollar-security-section-2-2-list-desc-5": "Users and developers cannot easily assess the trustworthiness of deployed contracts, the extent of their security validation (e.g., code audits), or the presence of latent risks. While solutions exist for this purpose, many issues remain. Tooling that addresses these issues is not widely adopted, the standards that would unify the approaches remain fragmented, and some of the existing services are themselves centralized dependencies.", "page-trillion-dollar-security-section-2-2-list-title-6": "Compiler risks", "page-trillion-dollar-security-section-2-2-list-desc-6": "Compilers (the software that converts human readable code like Solidity into the bytecode used by the EVM itself) can have flaws which introduce errors into smart contracts before they are deployed. The Ethereum ecosystem today mostly depends on the solc compiler, meaning a bug could have widespread effects.", "page-trillion-dollar-security-section-2-2-list-title-7": "Programming language diversity and depth", @@ -161,7 +161,7 @@ "page-trillion-dollar-security-section-4-5-list-3": "Collusion among validators or relays. Coordinated behavior between validators or between relays and validators could reduce decentralization, or extract MEV.", "page-trillion-dollar-security-section-4-5-list-4": "Exploitation of edge-case incentives in MEV, proposer-builder separation, or liquid staking design. Actors may manipulate rare protocol conditions to gain outsized rewards.", "page-trillion-dollar-security-section-4-6-title": "4.6 Quantum risk", - "page-trillion-dollar-security-section-4-6-paragraph-1": "Ethereum's core cryptography (e.g. elliptic curve signatures like secp256k1) could one day be broken by quantum computers. While this is not an imminent risk, a credible threat could instantly render existing wallets, contracts, and staking keys vulnerable. This future challenge weakens Ethereum's long-term guarantees to users.", + "page-trillion-dollar-security-section-4-6-paragraph-1": "Ethereum's core cryptography (e.g., elliptic curve signatures like secp256k1) could one day be broken by quantum computers. While this is not an imminent risk, a credible threat could instantly render existing wallets, contracts, and staking keys vulnerable. This future challenge weakens Ethereum's long-term guarantees to users.", "page-trillion-dollar-security-section-4-6-paragraph-2": "Migration paths to quantum-resistant cryptography (e.g., via post-quantum signature schemes) need to be designed, tested, and possibly embedded in the protocol years before they are needed. Organizations across the Ethereum ecosystem, including the Ethereum Foundation, are actively exploring these options and monitoring risks.", "page-trillion-dollar-security-section-5-paragraph-1": "Even an idealized blockchain ecosystem will have risks, attacks, and vulnerabilities. When things do go wrong, there must be effective systems to mitigate, detect and respond. Challenges here include:", "page-trillion-dollar-security-section-5-list-title-1": "Reaching the affected team", @@ -187,7 +187,7 @@ "page-trillion-dollar-security-section-6-2-paragraph-1": "Ethereum hosts significant amounts of real world assets, where the assets are held offchain in bank accounts or other deposits, which are then traded onchain via tokens that represent a claim on the offchain assets. For instance, many large stablecoins function this way.", "page-trillion-dollar-security-section-6-2-paragraph-2": "The institutions that hold the offchain deposits may have influence over the Ethereum ecosystem. For instance, during an extreme scenario where there is a contentious fork or network upgrade, large depositors can influence which chain becomes widely accepted by only choosing to recognize tokens on one chain or the other.", "page-trillion-dollar-security-section-6-3-title": "6.3 Regulatory attack or pressure", - "page-trillion-dollar-security-section-6-3-paragraph": "Governments and regulators could pressure various entities that control important components of the Ethereum stack to censor or otherwise interfere with the Ethereum protocol. Institutional users of Ethereum could also be impacted by these pressures, which would have further consequences for their users (e.g. a bank who can no longer offer certain crypto products due to regulatory bans).", + "page-trillion-dollar-security-section-6-3-paragraph": "Governments and regulators could pressure various entities that control important components of the Ethereum stack to censor or otherwise interfere with the Ethereum protocol. Institutional users of Ethereum could also be impacted by these pressures, which would have further consequences for their users (e.g., a bank who can no longer offer certain crypto products due to regulatory bans).", "page-trillion-dollar-security-section-6-4-title": "6.4 Organizational capture of governance", "page-trillion-dollar-security-section-6-4-paragraph-1": "Ethereum's open source governance and development processes are driven by a diverse and global set of teams and companies that maintain core client software, infrastructure, and tooling.", "page-trillion-dollar-security-section-6-4-paragraph-2": "Various forms of influence (corporate acquisitions, funding dependencies, employment of key contributors, conflicts of interest inside existing orgs) could gradually shift the culture and priorities of Ethereum governance. This may lead to alignment with specific commercial or external interests that diverge from the community-driven ethos and established roadmap, potentially weakening Ethereum's neutrality and resilience over time.", From 9e1bc1e35c2d94ab203739774381e5bd653b2ce0 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:56:07 -0500 Subject: [PATCH 115/212] hard stops on page-bug-bounty.json --- src/intl/en/page-bug-bounty.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/intl/en/page-bug-bounty.json b/src/intl/en/page-bug-bounty.json index 0719e9adbb9..a3d747fbbe2 100644 --- a/src/intl/en/page-bug-bounty.json +++ b/src/intl/en/page-bug-bounty.json @@ -19,7 +19,7 @@ "page-upgrades-bug-bounty-email-us": "Email us:", "page-upgrades-bug-bounty-help-links": "Helpful links", "page-upgrades-bug-bounty-hunting": "Bug hunting rules", - "page-upgrades-bug-bounty-hunting-desc": "The bug bounty program is an experimental and discretionary rewards program for our active Ethereum community to encourage and reward those who are helping to improve the platform. It is not a competition. You should know that we can cancel the program at any time, and awards are at the sole discretion of Ethereum Foundation bug bounty panel. In addition, we are not able to issue awards to individuals who are on sanctions lists or who are in countries on sanctions lists (e.g. North Korea, Iran, etc). Local laws require us to ask for proof of your identity. You are responsible for all taxes. All awards are subject to applicable law. Finally, your testing must not violate any law or compromise any data that is not yours and must take place on local running testnets.", + "page-upgrades-bug-bounty-hunting-desc": "The bug bounty program is an experimental and discretionary rewards program for our active Ethereum community to encourage and reward those who are helping to improve the platform. It is not a competition. You should know that we can cancel the program at any time, and awards are at the sole discretion of Ethereum Foundation bug bounty panel. In addition, we are not able to issue awards to individuals who are on sanctions lists or who are in countries on sanctions lists (e.g., North Korea, Iran, etc). Local laws require us to ask for proof of your identity. You are responsible for all taxes. All awards are subject to applicable law. Finally, your testing must not violate any law or compromise any data that is not yours and must take place on local running testnets.", "page-upgrades-bug-bounty-hunting-leaderboard": "Consensus Layer Bug Bounty leaderboard", "page-upgrades-bug-bounty-hunting-execution-leaderboard": "Execution Layer Bug Bounty leaderboard", "page-upgrades-bug-bounty-hunting-leaderboard-subtitle": "Find consensus layer bugs to get added to this leaderboard", From e85e18f8f47252f7b736cc48e883df892337c120 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:57:04 -0500 Subject: [PATCH 116/212] hard stops on glossary.json --- src/intl/en/glossary.json | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/intl/en/glossary.json b/src/intl/en/glossary.json index 021a80ed98a..71037454e60 100644 --- a/src/intl/en/glossary.json +++ b/src/intl/en/glossary.json @@ -62,7 +62,7 @@ "committee-term": "Committee", "committee-definition": "A group of at least 128 validators assigned to validate blocks in each slot. One of the validators in the committee is the aggregator, responsible for aggregating the signatures of all other validators in the committee that agree on an attestation. Not to be confused with sync committee.", "computational-infeasibility-term": "Computational infeasibility", - "computational-infeasibility-definition": "A process is computationally infeasible if it would take an impracticably long time (e.g. billions of years) to do it for anyone who might conceivably have an interest in carrying it out.", + "computational-infeasibility-definition": "A process is computationally infeasible if it would take an impracticably long time (e.g., billions of years) to do it for anyone who might conceivably have an interest in carrying it out.", "consensus-term": "Consensus", "consensus-definition": "When more than 2/3 of the computers in a network agree that they have the same set of records, making sure everyone is on the same page. This isn't about the rules they follow, but making sure they all have the same information.", "consensus-client-term": "Consensus client", @@ -112,7 +112,7 @@ "distributed-hash-table-term": "Distributed hash table (DHT)", "distributed-hash-table-definition": "A data structure containing `(key, value)` pairs used by Ethereum nodes to identify peers to connect to and determine which protocols to use to communicate.", "double-spend-term": "Double spend", - "double-spend-definition": "A deliberate blockchain fork, where a user with a sufficiently large amount of mining power/stake sends a transaction moving some currency offchain (e.g. exiting into fiat money or making an offchain purchase) then reorganizing the blockchain to remove that transaction. A successful double spend leaves the attacker with both their on and offchain assets.", + "double-spend-definition": "A deliberate blockchain fork, where a user with a sufficiently large amount of mining power/stake sends a transaction moving some currency offchain (e.g., exiting into fiat money or making an offchain purchase) then reorganizing the blockchain to remove that transaction. A successful double spend leaves the attacker with both their on and offchain assets.", "ecdsa-term": "Elliptic Curve Digital Signature Algorithm (ECDSA)", "ecdsa-definition": "A cryptographic algorithm used by Ethereum to ensure that funds can only be spent by their owners. It's the preferred method for creating public and private keys. Relevant for account address generation and transaction verification.", "encryption-term": "Encryption", @@ -272,7 +272,7 @@ "peer-term": "Peer", "peer-definition": "Connected computers running Ethereum client software that have identical copies of the blockchain.", "peer-to-peer-network-term": "Peer-to-peer network", - "peer-to-peer-network-definition": "A network of computers (peers) that are collectively able to perform functionalities without the need for centralized, server-based services.
This setup is often used for sharing files (I.e. Bit torrent), information, or digital currencies, allowing for more direct and potentially more efficient exchanges between users.", + "peer-to-peer-network-definition": "A network of computers (peers) that are collectively able to perform functionalities without the need for centralized, server-based services.
This setup is often used for sharing files (i.e., Bit torrent), information, or digital currencies, allowing for more direct and potentially more efficient exchanges between users.", "permissionless-term": "Permissionless", "permissionless-definition": "Permissionless means anyone can join and use a system like Ethereum. It's open for everyone to participate and doesn't require any approval.", "plasma-term": "Plasma", From bafc266286e2f1ecfa73dc6d295fe668f81bb2e7 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:57:48 -0500 Subject: [PATCH 117/212] hard stops on useOnClickOutside.ts --- src/hooks/useOnClickOutside.ts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hooks/useOnClickOutside.ts b/src/hooks/useOnClickOutside.ts index 17b529c0605..d885228ca34 100644 --- a/src/hooks/useOnClickOutside.ts +++ b/src/hooks/useOnClickOutside.ts @@ -1,7 +1,7 @@ import { RefObject, useEffect } from "react" // Use with `ref` on a component to handle clicks outside of ref element -// e.g. to hide the component (see Search or NavDropdown) +// e.g., to hide the component (see Search or NavDropdown) export const useOnClickOutside = ( ref: RefObject, handler: () => void, From c03ef010a20f6844061f3f7c6d3f8376efc57289 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:58:18 -0500 Subject: [PATCH 118/212] hard stops on Link.tsx --- src/components/ui/Link.tsx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/components/ui/Link.tsx b/src/components/ui/Link.tsx index 97b2bfc2093..97ae431d352 100644 --- a/src/components/ui/Link.tsx +++ b/src/components/ui/Link.tsx @@ -44,13 +44,13 @@ export type LinkProps = BaseProps & * Link wrapper which handles: * * - Hashed links - * e.g. + * e.g., * * - External links - * e.g. + * e.g., * * - PDFs & static files (which open in a new tab) - * e.g. + * e.g., */ export const BaseLink = forwardRef(function Link( { From b5f5d1aaa99e370efaabe7f24a24a3f4fe43a3d6 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:58:54 -0500 Subject: [PATCH 119/212] hard stops on breadcrumbs/index.tsx --- src/components/Breadcrumbs/index.tsx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/components/Breadcrumbs/index.tsx b/src/components/Breadcrumbs/index.tsx index fff98de3952..4907b830959 100644 --- a/src/components/Breadcrumbs/index.tsx +++ b/src/components/Breadcrumbs/index.tsx @@ -31,14 +31,14 @@ type Crumb = { // TODO: update docs after removing pathname and slug logic // Generate crumbs from slug -// e.g. "/eth2/proof-of-stake/" will generate: +// e.g., "/eth2/proof-of-stake/" will generate: // [ // { fullPath: "/", text: "HOME" }, // { fullPath: "/eth2/", text: "ETH2" }, // { fullPath: "/eth2/proof-of-stake/", text: "PROOF OF STAKE" }, // ] // `startDepth` will trim breadcrumbs -// e.g. startDepth=1 will generate: +// e.g., startDepth=1 will generate: // [ // { fullPath: "/eth2/", text: "ETH2" }, // { fullPath: "/eth2/proof-of-stake/", text: "PROOF OF STAKE" }, @@ -54,7 +54,7 @@ const Breadcrumbs = ({ slug, startDepth = 0, ...props }: BreadcrumbsProps) => { const sliced = slugChunk.filter((item) => !!item) const crumbs = [ - // If homepage (e.g. "en"), set text to "home" translation + // If homepage (e.g., "en"), set text to "home" translation ...(hasHome ? [ { From 792b38c4b086ee15184f4877b84c962e3327c7c8 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:59:23 -0500 Subject: [PATCH 120/212] hard stops on YouTube.tsx --- src/components/YouTube.tsx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/components/YouTube.tsx b/src/components/YouTube.tsx index 58e4e26128b..6649679ee0b 100644 --- a/src/components/YouTube.tsx +++ b/src/components/YouTube.tsx @@ -10,10 +10,10 @@ import "react-lite-youtube-embed/dist/LiteYouTubeEmbed.css" /** * @param {id} ID of the YouTube video * URLs come in format: https://www.youtube.com/watch?v= or https://www.youtube.com/embed/ - * e.g. For https://www.youtube.com/watch?v=H-O3r2YMWJ4 the `id` is H-O3r2YMWJ4 + * e.g., For https://www.youtube.com/watch?v=H-O3r2YMWJ4 the `id` is H-O3r2YMWJ4 * @param {start} Start time of the video in seconds * URLs come in format: https://www.youtube.com/watch?v=&t= or: https://www.youtube.com/embed/?start= - * e.g. For https://www.youtube.com/watch?v=H-O3r2YMWJ4&t=123 the `start` is 123 (which means 123 seconds) + * e.g., For https://www.youtube.com/watch?v=H-O3r2YMWJ4&t=123 the `start` is 123 (which means 123 seconds) * @returns Embedded YouTube video component */ From ae25cb414b6978109a94003c15e794b61ead2172 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 09:59:46 -0500 Subject: [PATCH 121/212] hard stops on TooltipLink.tsx --- src/components/TooltipLink.tsx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/components/TooltipLink.tsx b/src/components/TooltipLink.tsx index e02fa6e93f9..0041b87513c 100644 --- a/src/components/TooltipLink.tsx +++ b/src/components/TooltipLink.tsx @@ -28,7 +28,7 @@ function TooltipLink(props: Props) { const matches = href.match(regex) // get the `termKey` from the `href` - // e.g. in `/glossary/#new-term` => "new-term" is the `termKey` + // e.g., in `/glossary/#new-term` => "new-term" is the `termKey` if (matches?.length) { const termKey = matches[1] From 8a445dda9ce901cba9bc32c44ad9d8812a13d63a Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:00:06 -0500 Subject: [PATCH 122/212] hard stops on Codeblock.tsx --- src/components/Codeblock.tsx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/components/Codeblock.tsx b/src/components/Codeblock.tsx index 3e014544463..5a07c70e7c9 100644 --- a/src/components/Codeblock.tsx +++ b/src/components/Codeblock.tsx @@ -240,7 +240,7 @@ const Codeblock = ({ shouldShowCopyWidget || totalLines - 1 > LINES_BEFORE_COLLAPSABLE return ( - /* Overwrites codeblocks inheriting RTL styling in Right-To-Left script languages (e.g. Arabic) */ + /* Overwrites codeblocks inheriting RTL styling in Right-To-Left script languages (e.g., Arabic) */ /* Context: https://github.com/ethereum/ethereum-org-website/issues/6202 */
Date: Tue, 21 Oct 2025 10:00:43 -0500 Subject: [PATCH 123/212] hard stops on review-process.md --- docs/review-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/review-process.md b/docs/review-process.md index c696aa279e9..c10fc73d391 100644 --- a/docs/review-process.md +++ b/docs/review-process.md @@ -30,7 +30,7 @@ Any new feature correlated with an approved issue is of medium priority. Similar ### Content -Content PRs are considered medium-priority. Depending on their content, they can be very high-impact but also a high effort to go through the various stages of content review to ensure the content meets the standards we aim for. Content PRs can be broken into two categories: major content (e.g. a new page) and minor content changes (e.g. a new section to an existing page). Typo or grammar fixes are considered separately. +Content PRs are considered medium-priority. Depending on their content, they can be very high-impact but also a high effort to go through the various stages of content review to ensure the content meets the standards we aim for. Content PRs can be broken into two categories: major content (e.g., a new page) and minor content changes (e.g., a new section to an existing page). Typo or grammar fixes are considered separately. **Timeline:** Major content should be merged within 30 days of opening. Minor content changes within 14 days of opening. From 1484245de955122a53c7227d77551793494df89d Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:01:07 -0500 Subject: [PATCH 124/212] hard stops on code-of-conduct/index.md --- public/content/community/code-of-conduct/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/community/code-of-conduct/index.md b/public/content/community/code-of-conduct/index.md index 0d57d4a237c..55aaeb8da4d 100644 --- a/public/content/community/code-of-conduct/index.md +++ b/public/content/community/code-of-conduct/index.md @@ -68,7 +68,7 @@ Examples of unacceptable behavior by participants include: Violations of the code of conduct will normally be visible to the community as we try to do everything in open, public channels, allowing community members to self-police. -However, if something happens that you feel needs attention, you can raise it with someone who has a moderation role (e.g. discord guide) so that they can help investigate and execute the appropriate response. +However, if something happens that you feel needs attention, you can raise it with someone who has a moderation role (e.g., discord guide) so that they can help investigate and execute the appropriate response. When reporting, please include as much detail as possible, including specific examples and timestamps. This will help to ensure a fair outcome. From 523cf64213e397bd6e103bf1df0860a0985fb98a Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:03:04 -0500 Subject: [PATCH 125/212] hard stops on organizing/index.md --- public/content/community/events/organizing/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/community/events/organizing/index.md b/public/content/community/events/organizing/index.md index aaee9ef1055..961c3e00d5d 100644 --- a/public/content/community/events/organizing/index.md +++ b/public/content/community/events/organizing/index.md @@ -55,7 +55,7 @@ By providing diverse opportunities for learning, collaboration, and growth, you Organizing a successful Ethereum conference or community event requires careful timing and consideration. The right moment depends on a variety of factors that contribute to the event's overall success. -You should take into consideration community maturity, market conditions, whether you have a team, and whether there is a local scene (e.g. potential sponsors). +You should take into consideration community maturity, market conditions, whether you have a team, and whether there is a local scene (e.g., potential sponsors). ### KYC — Know your community {#kyc-know-your-community} From 977453f4b63131241a9e8a1c1bfef6e0ca5325ec Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:03:17 -0500 Subject: [PATCH 126/212] hard stops on research/index.md --- public/content/community/research/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/community/research/index.md b/public/content/community/research/index.md index b3d326f67cf..f1c260a2cc7 100644 --- a/public/content/community/research/index.md +++ b/public/content/community/research/index.md @@ -57,7 +57,7 @@ The execution layer is concerned with executing transactions, running the [Ether - building out light client support; - researching gas limits; -- and incorporating new data structures (e.g. Verkle Tries). +- and incorporating new data structures (e.g., Verkle Tries). #### Background reading {#background-reading-1} @@ -266,7 +266,7 @@ Validators use Ethereum's native asset (ether) as collateral against dishonest b ### Liquid staking and derivatives {#liquid-staking-and-derivatives} -Liquid staking allows users with less than 32 ETH to receive staking yields by swapping ether for a token representing staked ether that can be used in DeFi. However, the incentives and market dynamics associated with liquid staking are still being discovered, as well as its effect on Ethereum's security (e.g. centralization risks). +Liquid staking allows users with less than 32 ETH to receive staking yields by swapping ether for a token representing staked ether that can be used in DeFi. However, the incentives and market dynamics associated with liquid staking are still being discovered, as well as its effect on Ethereum's security (e.g., centralization risks). #### Background reading {#background-reading-12} From dcccfa0357d15c9ad35e93411cd283c3d01e42db Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:03:30 -0500 Subject: [PATCH 127/212] hard stops on adding-layer-2s/index.md --- public/content/contributing/adding-layer-2s/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/contributing/adding-layer-2s/index.md b/public/content/contributing/adding-layer-2s/index.md index 6f3a6574af4..063a1b8b3fa 100644 --- a/public/content/contributing/adding-layer-2s/index.md +++ b/public/content/contributing/adding-layer-2s/index.md @@ -78,7 +78,7 @@ _We do not consider other scaling solutions that don't use Ethereum for data ava **Links to dapps in the layer 2 ecosystem** -- We want to be able to provide information on what users can expect to be able to do on this layer 2. (e.g. https://portal.arbitrum.io/, https://www.optimism.io/apps) +- We want to be able to provide information on what users can expect to be able to do on this layer 2. (e.g., https://portal.arbitrum.io/, https://www.optimism.io/apps) **Token contract lists** From e8e618608764f020d028d25a5f2890aac30ec5d8 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:04:11 -0500 Subject: [PATCH 128/212] hard stops on style-guide/index.md --- public/content/contributing/style-guide/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/contributing/style-guide/index.md b/public/content/contributing/style-guide/index.md index 351af2dcf61..4c9db1d453a 100644 --- a/public/content/contributing/style-guide/index.md +++ b/public/content/contributing/style-guide/index.md @@ -108,15 +108,15 @@ Ethereum.org documentation (and content at large) aims to maintain a credibly ne **Grand, unverifiable claims about Ethereum or adjacent technologies** -> e.g. _"Ethereum will take over the world because..."_ +> e.g., _"Ethereum will take over the world because..."_ **Hostile or confrontational language aimed at any organization or person** -> e.g. _"Company X is bad because they are centralized!"_ +> e.g., _"Company X is bad because they are centralized!"_ **Politically charged rhetoric** -> e.g. _"This political party is better for decentralization because..."_ +> e.g., _"This political party is better for decentralization because..."_ ### Acronyms {#acronyms} From 80ff3e9736bc45a251d5683793e193444ae25e57 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:45:42 -0500 Subject: [PATCH 129/212] hard stops on json-rpc/index --- public/content/developers/docs/apis/json-rpc/index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/public/content/developers/docs/apis/json-rpc/index.md b/public/content/developers/docs/apis/json-rpc/index.md index 6b85f335185..d39739e62c7 100755 --- a/public/content/developers/docs/apis/json-rpc/index.md +++ b/public/content/developers/docs/apis/json-rpc/index.md @@ -88,7 +88,7 @@ On this page we provide examples of how to use individual JSON_RPC API endpoints Examples of using the JSON_RPC API by making [curl](https://curl.se) requests to an Ethereum node are provided below. Each example includes a description of the specific endpoint, its parameters, return type, and a worked example of how it should be used. -The curl requests might return an error message relating to the content type. This is because the `--data` option sets the content type to `application/x-www-form-urlencoded`. If your node does complain about this, manually set the header by placing `-H "Content-Type: application/json"` at the start of the call. The examples also do not include the URL/IP & port combination which must be the last argument given to curl (e.g. `127.0.0.1:8545`). A complete curl request including these additional data takes the following form: +The curl requests might return an error message relating to the content type. This is because the `--data` option sets the content type to `application/x-www-form-urlencoded`. If your node does complain about this, manually set the header by placing `-H "Content-Type: application/json"` at the start of the call. The examples also do not include the URL/IP & port combination which must be the last argument given to curl (e.g., `127.0.0.1:8545`). A complete curl request including these additional data takes the following form: ```shell curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545 @@ -912,7 +912,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA The sign method calculates an Ethereum specific signature with: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`. -By adding a prefix to the message makes the calculated signature recognizable as an Ethereum specific signature. This prevents misuse where a malicious dapp can sign arbitrary data (e.g. transaction) and use the signature to impersonate the victim. +By adding a prefix to the message makes the calculated signature recognizable as an Ethereum specific signature. This prevents misuse where a malicious dapp can sign arbitrary data (e.g., transaction) and use the signature to impersonate the victim. Note: the address to sign with must be unlocked. @@ -1649,8 +1649,8 @@ params: [ **Returns** `Array` - Array of log objects, or an empty array if nothing has changed since last poll. -- For filters created with `eth_newBlockFilter` the return are block hashes (`DATA`, 32 Bytes), e.g. `["0x3454645634534..."]`. -- For filters created with `eth_newPendingTransactionFilter ` the return are transaction hashes (`DATA`, 32 Bytes), e.g. `["0x6345343454645..."]`. +- For filters created with `eth_newBlockFilter` the return are block hashes (`DATA`, 32 Bytes), e.g., `["0x3454645634534..."]`. +- For filters created with `eth_newPendingTransactionFilter ` the return are transaction hashes (`DATA`, 32 Bytes), e.g., `["0x6345343454645..."]`. - For filters created with `eth_newFilter` logs are objects with following params: - `removed`: `TAG` - `true` when the log was removed, due to a chain reorganization. `false` if its a valid log. - `logIndex`: `QUANTITY` - integer of the log index position in the block. `null` when its pending log. @@ -1660,7 +1660,7 @@ params: [ - `blockNumber`: `QUANTITY` - the block number where this log was in. `null` when its pending. `null` when its pending log. - `address`: `DATA`, 20 Bytes - address from which this log originated. - `data`: `DATA` - contains zero or more 32 Bytes non-indexed arguments of the log. - - `topics`: `Array of DATA` - Array of 0 to 4 32 Bytes `DATA` of indexed log arguments. (In _solidity_: The first topic is the _hash_ of the signature of the event (e.g. `Deposit(address,bytes32,uint256)`), except you declared the event with the `anonymous` specifier.) + - `topics`: `Array of DATA` - Array of 0 to 4 32 Bytes `DATA` of indexed log arguments. (In _solidity_: The first topic is the _hash_ of the signature of the event (e.g., `Deposit(address,bytes32,uint256)`), except you declared the event with the `anonymous` specifier.) - **Example** ```js From 740fec292913e759724cfb37b785698a30f6fd96 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:46:43 -0500 Subject: [PATCH 130/212] hard stops on mining-algorithms/ethash/index --- .../pow/mining/mining-algorithms/ethash/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md index 7dc41181c25..8229e1c03fe 100644 --- a/public/content/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md +++ b/public/content/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -47,7 +47,7 @@ ACCESSES = 64 # number of accesses in hashimoto loop Ethereum's development coincided with the development of the SHA3 standard, and the standards process made a late change in the padding of the finalized hash algorithm, so that Ethereum's "sha3_256" and "sha3_512" hashes are not standard sha3 hashes, but a variant often referred -to as "Keccak-256" and "Keccak-512" in other contexts. See discussion, e.g. [here](https://eips.ethereum.org/EIPS/eip-1803), [here](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), or [here](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). +to as "Keccak-256" and "Keccak-512" in other contexts. See discussion, e.g., [here](https://eips.ethereum.org/EIPS/eip-1803), [here](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), or [here](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). Please keep that in mind as "sha3" hashes are referred to in the description of the algorithm below. From 90ebb4dac47b3ea023fad89a78632c55b6fe77e3 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:47:17 -0500 Subject: [PATCH 131/212] hard stops on particia-merkle-trie/index --- .../patricia-merkle-trie/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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 fce9985f2d2..f210f22b29f 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 @@ -68,7 +68,7 @@ A "Merkle" Radix tree is built by linking nodes using deterministically-generate It is impossible for an attacker to provide a proof of a `(path, value)` pair that does not exist since the root hash is ultimately based on all hashes below it. Any underlying modification would change the root hash. You can think of the hash as a compressed representation of structural information about the data, secured by the pre-image protection of the hashing function. -We'll refer to an atomic unit of a radix tree (e.g. a single hex character, or 4 bit binary number) as a "nibble". While traversing a path one nibble at a time, as described above, nodes can maximally refer to 16 children but include a `value` element. We, hence, represent them as an array of length 17. We call these 17-element arrays "branch nodes". +We'll refer to an atomic unit of a radix tree (e.g., a single hex character, or 4 bit binary number) as a "nibble". While traversing a path one nibble at a time, as described above, nodes can maximally refer to 16 children but include a `value` element. We, hence, represent them as an array of length 17. We call these 17-element arrays "branch nodes". ## Merkle Patricia Trie {#merkle-patricia-trees} @@ -206,7 +206,7 @@ There is one global state trie, and it is updated every time a client processes ### Storage Trie {#storage-trie} -Storage trie is where _all_ contract data lives. There is a separate storage trie for each account. To retrieve values at specific storage positions at a given address the storage address, integer position of the stored data in the storage, and the block ID are required. These can then be passed as arguments to the `eth_getStorageAt` defined in the JSON-RPC API, e.g. to retrieve the data in storage slot 0 for address `0x295a70b2de5e3953354a6a8344e616ed314d7251`: +Storage trie is where _all_ contract data lives. There is a separate storage trie for each account. To retrieve values at specific storage positions at a given address the storage address, integer position of the stored data in the storage, and the block ID are required. These can then be passed as arguments to the `eth_getStorageAt` defined in the JSON-RPC API, e.g., to retrieve the data in storage slot 0 for address `0x295a70b2de5e3953354a6a8344e616ed314d7251`: ```bash curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 From ddada517846622be98c3db160ecc64d2c6e06bf9 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:48:12 -0500 Subject: [PATCH 132/212] hard stops on dex-design-best-practice/index --- .../docs/design-and-ux/dex-design-best-practice/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/developers/docs/design-and-ux/dex-design-best-practice/index.md index 05e659dfe1f..addc2140177 100644 --- a/public/content/developers/docs/design-and-ux/dex-design-best-practice/index.md +++ b/public/content/developers/docs/design-and-ux/dex-design-best-practice/index.md @@ -72,7 +72,7 @@ In the early days of DeFi, the fiat equivalent was often missing. If you are bui On the second field (the one where you choose the token you are swapping to) you can also include the price impact next to the fiat currency amount, by calculating the difference between the input amount and estimated output amounts. This is quite a useful detail to include. -Percentage buttons (e.g. 25%, 50%, 75%) can be a useful feature, but they take up more space, add more call to actions, and add more mental load. Same with percentage sliders. Some of these UI decisions will depend on your brand and your user type. +Percentage buttons (e.g., 25%, 50%, 75%) can be a useful feature, but they take up more space, add more call to actions, and add more mental load. Same with percentage sliders. Some of these UI decisions will depend on your brand and your user type. Extra details can be shown below the main form. As this type of info is mostly for pro users, it makes sense to either: - keep it as minimal as possible, or; @@ -165,7 +165,7 @@ The bottom line is that it probably doesn’t make a huge difference to usabilit It’s been mildly interesting to see the fashion change with time. Uniswap initially had the token on the left, but has since moved it to the right. Sushiswap also made this change during a design upgrade. Most, but not all, protocols have followed suit. -Financial convention traditionally puts the currency symbol before the number, e.g. $50, €50, £50, but we *say* 50 dollars, 50 Euros, 50 pounds. +Financial convention traditionally puts the currency symbol before the number, e.g., $50, €50, £50, but we *say* 50 dollars, 50 Euros, 50 pounds. To the general user - especially someone who reads left to right, top to bottom - token on the right probably feels more natural. From d7dd9eb57d3249f64be14d23b55d5d429ea14dbf Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:48:47 -0500 Subject: [PATCH 133/212] hard stops on pools/index --- public/content/translations/zh-tw/staking/pools/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/zh-tw/staking/pools/index.md b/public/content/translations/zh-tw/staking/pools/index.md index 6e39735cb6c..9a2360e00f2 100644 --- a/public/content/translations/zh-tw/staking/pools/index.md +++ b/public/content/translations/zh-tw/staking/pools/index.md @@ -26,7 +26,7 @@ summaryPoints: - + From 28813726f6a2710e4ecaeb786dcefa23ee46cf27 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:50:02 -0500 Subject: [PATCH 134/212] hard stops on erc20-annotated-code/index --- .../zh/developers/tutorials/erc20-annotated-code/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/translations/zh/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/zh/developers/tutorials/erc20-annotated-code/index.md index bf73e3877c1..18dc44882f2 100644 --- a/public/content/translations/zh/developers/tutorials/erc20-annotated-code/index.md +++ b/public/content/translations/zh/developers/tutorials/erc20-annotated-code/index.md @@ -594,7 +594,7 @@ B： * @dev Moves tokens `amount` from `sender` to `recipient`. * * This is internal function is equivalent to {transfer}, and can be used to - * e.g. implement automatic token fees, slashing mechanisms, etc. + * e.g., implement automatic token fees, slashing mechanisms, etc. * * Emits a {Transfer} event. * @@ -715,7 +715,7 @@ B： * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens. * * This internal function is equivalent to `approve`, and can be used to - * e.g. set automatic allowances for certain subsystems, etc. + * e.g., set automatic allowances for certain subsystems, etc. * * Emits an {Approval} event. * From 0729054c87a81dd69d5b761e6406efd1b76635b5 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:50:15 -0500 Subject: [PATCH 135/212] hard stops nft-minter/index --- .../zh/developers/tutorials/nft-minter/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/translations/zh/developers/tutorials/nft-minter/index.md b/public/content/translations/zh/developers/tutorials/nft-minter/index.md index 7821c9f0446..19b68ed3c1b 100644 --- a/public/content/translations/zh/developers/tutorials/nft-minter/index.md +++ b/public/content/translations/zh/developers/tutorials/nft-minter/index.md @@ -166,19 +166,19 @@ return (

🖼 Link to asset:

setURL(event.target.value)} />

🤔 Name:

setName(event.target.value)} />

✍️ Description:

setDescription(event.target.value)} /> From 9f0cb04e5a10f0a65e38595958d8a8071a67eb19 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:50:30 -0500 Subject: [PATCH 136/212] hard stops on optimism-std-bridge-annotated-code/index --- .../tutorials/optimism-std-bridge-annotated-code/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/zh/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/zh/developers/tutorials/optimism-std-bridge-annotated-code/index.md index be1a3248231..c5185d455c7 100644 --- a/public/content/translations/zh/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/translations/zh/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -725,7 +725,7 @@ contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled { ```solidity /** * @dev Performs the logic for deposits by informing the L2 Deposited Token - * contract of the deposit and calling a handler to lock the L1 funds. (e.g. transferFrom) + * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom) * * @param _l1Token Address of the L1 ERC20 we are depositing * @param _l2Token Address of the L1 respective L2 ERC20 From 20e7200df31d3bcd54dff9811048e42e6fcccc9e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:50:43 -0500 Subject: [PATCH 137/212] hard stops on staking/pools/index --- public/content/translations/zh/staking/pools/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/zh/staking/pools/index.md b/public/content/translations/zh/staking/pools/index.md index 4e9397a23c7..6748a44fb09 100644 --- a/public/content/translations/zh/staking/pools/index.md +++ b/public/content/translations/zh/staking/pools/index.md @@ -26,7 +26,7 @@ summaryPoints: - + From 3ac36a3719dc974efb67ec74c9bf6e041cea5be6 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:51:11 -0500 Subject: [PATCH 138/212] hard stops on staking/pools/index --- public/content/translations/yo/staking/pools/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/yo/staking/pools/index.md b/public/content/translations/yo/staking/pools/index.md index 997987d48a0..c49c97cbdd4 100644 --- a/public/content/translations/yo/staking/pools/index.md +++ b/public/content/translations/yo/staking/pools/index.md @@ -26,7 +26,7 @@ Ní afikún si àwọn àǹfààní ti ati sọ tẹle ninu [ọ̀rọ̀-agbekal - + From 6918c098ed567255756b45137cfec880404789e9 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:54:42 -0500 Subject: [PATCH 139/212] hard stops on staking/pools/index --- public/content/translations/ru/staking/pools/index.md | 2 +- public/content/translations/sk/staking/pools/index.md | 2 +- public/content/translations/tl/staking/pools/index.md | 2 +- public/content/translations/tr/staking/pools/index.md | 2 +- public/content/translations/uk/staking/pools/index.md | 2 +- public/content/translations/uz/staking/pools/index.md | 2 +- public/content/translations/vi/staking/pools/index.md | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/public/content/translations/ru/staking/pools/index.md b/public/content/translations/ru/staking/pools/index.md index 1e4fe940621..fa221cf113e 100644 --- a/public/content/translations/ru/staking/pools/index.md +++ b/public/content/translations/ru/staking/pools/index.md @@ -26,7 +26,7 @@ summaryPoints: - + diff --git a/public/content/translations/sk/staking/pools/index.md b/public/content/translations/sk/staking/pools/index.md index 8ad10c6a772..3a4771e04ae 100644 --- a/public/content/translations/sk/staking/pools/index.md +++ b/public/content/translations/sk/staking/pools/index.md @@ -26,7 +26,7 @@ Okrem výhod, ktoré sme načrtli v našom [úvode do stakingu](/staking/), prin - + diff --git a/public/content/translations/tl/staking/pools/index.md b/public/content/translations/tl/staking/pools/index.md index 400baf651d3..50f066fb1ff 100644 --- a/public/content/translations/tl/staking/pools/index.md +++ b/public/content/translations/tl/staking/pools/index.md @@ -26,7 +26,7 @@ Bukod sa mga benepisyo na aming inilahad sa aming [panimula sa staking](/staking - + diff --git a/public/content/translations/tr/staking/pools/index.md b/public/content/translations/tr/staking/pools/index.md index 2aaf2adba36..2d3668e12a9 100644 --- a/public/content/translations/tr/staking/pools/index.md +++ b/public/content/translations/tr/staking/pools/index.md @@ -26,7 +26,7 @@ Bazı havuzlar, fonların bir sözleşmeye yatırılabileceği, bahis tutarını - + diff --git a/public/content/translations/uk/staking/pools/index.md b/public/content/translations/uk/staking/pools/index.md index 44f05c1c09b..23ff339ce81 100644 --- a/public/content/translations/uk/staking/pools/index.md +++ b/public/content/translations/uk/staking/pools/index.md @@ -26,7 +26,7 @@ summaryPoints: - + diff --git a/public/content/translations/uz/staking/pools/index.md b/public/content/translations/uz/staking/pools/index.md index 3b92536f297..d6625402cfc 100644 --- a/public/content/translations/uz/staking/pools/index.md +++ b/public/content/translations/uz/staking/pools/index.md @@ -26,7 +26,7 @@ Pul tikishning biz [kirish qismida](/staking/) ta’riflagan afzalliklaridan tas - + diff --git a/public/content/translations/vi/staking/pools/index.md b/public/content/translations/vi/staking/pools/index.md index 196e2e7ba2f..b1bde161de4 100644 --- a/public/content/translations/vi/staking/pools/index.md +++ b/public/content/translations/vi/staking/pools/index.md @@ -26,7 +26,7 @@ Ngoài những lợi ích mà chúng tôi đã nêu trong phần [giới thiệu - + From f5309c8abc0ae0506700aa538b5826811055aca7 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:54:57 -0500 Subject: [PATCH 140/212] hard stops on how-to-use-tellor-as-your-oracle/index --- .../tutorials/how-to-use-tellor-as-your-oracle/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ro/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md b/public/content/translations/ro/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md index 774f51a395f..7c4da94bc19 100644 --- a/public/content/translations/ro/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md +++ b/public/content/translations/ro/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md @@ -30,7 +30,7 @@ Tellor este un Oracol live și open-source gata de implementare. Acest ghid pent ## Prezentare generală {#overview} -Tellor is an oracle system where parties can request the value of an off-chain data point (e.g. BTC/USD) and reporters compete to add this value to an on-chain data-bank, accessible by all Ethereum smart contracts. The inputs to this data-bank are secured by a network of staked reporters. Tellor utilizes crypto-economic incentive mechanisms, rewarding honest data submissions by reporters and punishing bad actors through the issuance of Tellor’s token, Tributes (TRB) and a dispute mechanism. +Tellor is an oracle system where parties can request the value of an off-chain data point (e.g., BTC/USD) and reporters compete to add this value to an on-chain data-bank, accessible by all Ethereum smart contracts. The inputs to this data-bank are secured by a network of staked reporters. Tellor utilizes crypto-economic incentive mechanisms, rewarding honest data submissions by reporters and punishing bad actors through the issuance of Tellor’s token, Tributes (TRB) and a dispute mechanism. În acest tutorial vom trece în revistă: From 5ce67ca179c7698808329a932fc8d1b0f0d79653 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:55:16 -0500 Subject: [PATCH 141/212] hard stops on optimism-std-bridge-annotated-code/index --- .../tutorials/optimism-std-bridge-annotated-code/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ro/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/ro/developers/tutorials/optimism-std-bridge-annotated-code/index.md index 3546d2bb4a3..4ffc427fc42 100644 --- a/public/content/translations/ro/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/translations/ro/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -725,7 +725,7 @@ These two functions are wrappers around `_initiateERC20Deposit`, the function th ```solidity /** * @dev Performs the logic for deposits by informing the L2 Deposited Token - * contract of the deposit and calling a handler to lock the L1 funds. (e.g. transferFrom) + * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom) * * @param _l1Token Address of the L1 ERC20 we are depositing * @param _l2Token Address of the L1 respective L2 ERC20 From cd71ca1fa34ee553fa81e433af0405f4292a0092 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:55:34 -0500 Subject: [PATCH 142/212] hard stops on governance/index --- public/content/translations/tl/governance/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/tl/governance/index.md b/public/content/translations/tl/governance/index.md index 1633f5641eb..396273c82ca 100644 --- a/public/content/translations/tl/governance/index.md +++ b/public/content/translations/tl/governance/index.md @@ -48,7 +48,7 @@ May iba't ibang stakeholder sa [komunidad ng Ethereum](/community/), at may pape - **Mga Node Operator**: nagpapatakbo ang mga taong ito ng mga node na nagpaparami ng mga block at transaksyon, at hindi tinatanggap ng mga ito ang anumang hindi valid na transaksyon o block na matutuklasan ng mga ito. [Iba pang detalye tungkol sa mga node](/developers/docs/nodes-and-clients/). - **Mga EIP Author**: nagmumungkahi ang mga taong ito ng mga pagbabago sa Ethereum protocol, sa pamamagitan ng mga Ethereum Improvement Proposal (EIP). [Iba pang detalye tungkol sa EIPs](/eips/). - **Mga Validator**: nagpapatakbo ang mga taong ito ng mga node na makakapagdagdag ng mga bagong block sa Ethereum blockchain. -- **Mga Developer ng Protokol** (kilala rin bilang "Core Developers" ): these people maintain the various Ethereum implementations (e.g. go-ethereum, Nethermind, Besu, Erigon, Reth at the execution layer or Prysm, Lighthouse, Nimbus, Teku, Lodestar, Grandine at the consensus layer). [Iba pang detalye tungkol sa mga kliyente ng Ethereum](/developers/docs/nodes-and-clients/). +- **Mga Developer ng Protokol** (kilala rin bilang "Core Developers" ): these people maintain the various Ethereum implementations (e.g., go-ethereum, Nethermind, Besu, Erigon, Reth at the execution layer or Prysm, Lighthouse, Nimbus, Teku, Lodestar, Grandine at the consensus layer). [Iba pang detalye tungkol sa mga kliyente ng Ethereum](/developers/docs/nodes-and-clients/). _Tandaan: maaaring hindi lang sa isa sa mga grupong ito napapabilang ang sinumang indibidwal (hal. maaaring magtaguyod ng EIP, at magpatakbo ng beacon chain validator, at gumamit ng mga DeFi application ang isang developer ng protokol). Para malinaw itong maunawaan, pinakamadali kung pag-iiba-ibahin ang mga ito._ From 54a84eecc16d45136bc967d510bfa188316ed23e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:55:47 -0500 Subject: [PATCH 143/212] hard stops on nft-minter/index --- .../tr/developers/tutorials/nft-minter/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/translations/tr/developers/tutorials/nft-minter/index.md b/public/content/translations/tr/developers/tutorials/nft-minter/index.md index 45baf9d6ead..eef4bf3b35d 100644 --- a/public/content/translations/tr/developers/tutorials/nft-minter/index.md +++ b/public/content/translations/tr/developers/tutorials/nft-minter/index.md @@ -163,19 +163,19 @@ return (

🖼 Link to asset:

setURL(event.target.value)} />

🤔 Name:

setName(event.target.value)} />

✍️ Description:

setDescription(event.target.value)} /> From 7d4f419dd665e641098e514f07c12d2b627368f2 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:56:01 -0500 Subject: [PATCH 144/212] hard stops optimism-std-bridge-annotated-code/index --- .../tutorials/optimism-std-bridge-annotated-code/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/tr/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/tr/developers/tutorials/optimism-std-bridge-annotated-code/index.md index f6bcc4111b5..9fb38aa2b01 100644 --- a/public/content/translations/tr/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/translations/tr/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -725,7 +725,7 @@ Bu iki fonksiyon, gerçek ERC-20 yatırma işlemini yöneten fonksiyon olan `_in ```solidity /** * @dev Performs the logic for deposits by informing the L2 Deposited Token - * contract of the deposit and calling a handler to lock the L1 funds. (e.g. transferFrom) + * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom) * * @param _l1Token Address of the L1 ERC20 we are depositing * @param _l2Token Address of the L1 respective L2 ERC20 From 17711f0021e63ee3db0f39d4ad3fa3856521d4ea Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:56:32 -0500 Subject: [PATCH 145/212] hard stops on guide-to-smart-contract-security-tools/index --- .../tutorials/guide-to-smart-contract-security-tools/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ro/developers/tutorials/guide-to-smart-contract-security-tools/index.md b/public/content/translations/ro/developers/tutorials/guide-to-smart-contract-security-tools/index.md index 04ac95151e1..f04e638dce9 100644 --- a/public/content/translations/ro/developers/tutorials/guide-to-smart-contract-security-tools/index.md +++ b/public/content/translations/ro/developers/tutorials/guide-to-smart-contract-security-tools/index.md @@ -67,7 +67,7 @@ Dintre domeniile mari adesea relevante pentru contractele inteligente menționă - Echidna și Manticore sunt instrumentele preferate pentru a testa specificațiile mașinilor de stare. -- **Access controls.** If your system has privileged users (e.g. an owner, controllers, ...) you must ensure that (1) each user can only perform the authorized actions and (2) no user can block actions from a more privileged user. +- **Access controls.** If your system has privileged users (e.g., an owner, controllers, ...) you must ensure that (1) each user can only perform the authorized actions and (2) no user can block actions from a more privileged user. - Slither, Echidna și Manticore pot efectua verificarea controalelor corecte ale accesului. De exemplu, Slither poate să verifice că numai funcțiilor de pe lista albă le lipsește modificatorul „onlyOwner”. Echidna și Manticore sunt utile pentru un control al accesului mai complex, cum ar fi că o permisiune este acordată numai atunci când contractul atinge o anumită stare. From 6c7f75575c7909c6d4fe805b1ecc4aa37a9d263e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:57:01 -0500 Subject: [PATCH 146/212] hard stops on nodes-as-a-service/index --- .../docs/nodes-and-clients/nodes-as-a-service/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/translations/ro/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/ro/developers/docs/nodes-and-clients/nodes-as-a-service/index.md index 7485525bd61..e6dec5989e0 100644 --- a/public/content/translations/ro/developers/docs/nodes-and-clients/nodes-as-a-service/index.md +++ b/public/content/translations/ro/developers/docs/nodes-and-clients/nodes-as-a-service/index.md @@ -123,14 +123,14 @@ Iată o listă cu unii dintre cei mai cunoscuți furnizori de noduri Ethereum; n - 500+ administrative and service APIs - RESTful interface for Ethereum transaction submission (Apache Kafka backed) - Outbound streams for event delivery (Apache Kafka backed) - - Deep collection of "off-chain" and ancillary services (e.g. bilateral encrypted messaging transport) + - Deep collection of "off-chain" and ancillary services (e.g., bilateral encrypted messaging transport) - Straightforward network onboarding with governance and role-based access control - Sophisticated user management for both administrators and end users - Highly scalable, resilient, enterprise-grade infrastructure - Cloud HSM private key management - Ethereum Mainnet Tethering - ISO 27k and SOC 2, Type 2 certifications - - Dynamic runtime configuration (e.g. adding cloud integrations, altering node ingresses, etc.) + - Dynamic runtime configuration (e.g., adding cloud integrations, altering node ingresses, etc.) - Support for multi-cloud, multi-region and hybrid deployment orchestrations - Simple hourly SaaS-based pricing - SLAs and 24x7 support From 49b9380a48e523f2c5967760043e86dd9b5b09ec Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:57:29 -0500 Subject: [PATCH 147/212] hard stops on staking/pools/index --- public/content/translations/pt-br/staking/pools/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pt-br/staking/pools/index.md b/public/content/translations/pt-br/staking/pools/index.md index 151d6735e49..12d3a492a5e 100644 --- a/public/content/translations/pt-br/staking/pools/index.md +++ b/public/content/translations/pt-br/staking/pools/index.md @@ -26,7 +26,7 @@ Além dos benefícios delineados em nossa [introdução ao staking](/staking/), - + From 7163671ca7f268b09978ffe1382bd9ec3ddd3232 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:57:54 -0500 Subject: [PATCH 148/212] hard stops on optimism-std-bridge-annotated-code/index --- .../tutorials/optimism-std-bridge-annotated-code/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pt-br/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/pt-br/developers/tutorials/optimism-std-bridge-annotated-code/index.md index 7697cff63b4..563bb7c50e7 100644 --- a/public/content/translations/pt-br/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/translations/pt-br/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -725,7 +725,7 @@ Estas duas funções são wrappers em volta do `_initiateERC20Deposit`, a funç ```solidity /** * @dev Performs the logic for deposits by informing the L2 Deposited Token - * contract of the deposit and calling a handler to lock the L1 funds. (e.g. transferFrom) + * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom) * * @param _l1Token Address of the L1 ERC20 we are depositing * @param _l2Token Address of the L1 respective L2 ERC20 From 88e102f59e039e4145790c28e78ed742b2993e72 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:58:23 -0500 Subject: [PATCH 149/212] hard stops on nft-minter/index --- .../pt-br/developers/tutorials/nft-minter/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/translations/pt-br/developers/tutorials/nft-minter/index.md b/public/content/translations/pt-br/developers/tutorials/nft-minter/index.md index 9fe52ddba69..7915b9561ce 100644 --- a/public/content/translations/pt-br/developers/tutorials/nft-minter/index.md +++ b/public/content/translations/pt-br/developers/tutorials/nft-minter/index.md @@ -163,19 +163,19 @@ return (

🖼 Link to asset:

setURL(event.target.value)} />

🤔 Name:

setName(event.target.value)} />

✍️ Description:

setDescription(event.target.value)} /> From 555c7c43957c76bdb2a5a1001fdcdec834f7cb5a Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:59:03 -0500 Subject: [PATCH 150/212] hard stops on erc20-annotated-code/index --- .../pt-br/developers/tutorials/erc20-annotated-code/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/translations/pt-br/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/pt-br/developers/tutorials/erc20-annotated-code/index.md index b40a0838de7..8c69086d65a 100644 --- a/public/content/translations/pt-br/developers/tutorials/erc20-annotated-code/index.md +++ b/public/content/translations/pt-br/developers/tutorials/erc20-annotated-code/index.md @@ -593,7 +593,7 @@ Essas são as quatro funções que realmente funcionam: `_transfer`, `_mint`, `_ * @dev Moves tokens `amount` from `sender` to `recipient`. * * This is internal function is equivalent to {transfer}, and can be used to - * e.g. implement automatic token fees, slashing mechanisms, etc. + * e.g., implement automatic token fees, slashing mechanisms, etc. * * Emits a {Transfer} event. * @@ -714,7 +714,7 @@ Essa é a função que especifica as provisões. Observe que ela permite que um * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens. * * This internal function is equivalent to `approve`, and can be used to - * e.g. set automatic allowances for certain subsystems, etc. + * e.g., set automatic allowances for certain subsystems, etc. * * Emits an {Approval} event. * From c273563d0570542d85f0ce671bd1914e3f57360d Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:59:23 -0500 Subject: [PATCH 151/212] hard stops on staking/pools/index --- public/content/translations/pt/staking/pools/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pt/staking/pools/index.md b/public/content/translations/pt/staking/pools/index.md index e6970eaeeb9..ef825fed5d5 100644 --- a/public/content/translations/pt/staking/pools/index.md +++ b/public/content/translations/pt/staking/pools/index.md @@ -26,7 +26,7 @@ Para além dos benefícios que delineámos na nossa [introdução ao staking](/s - + From 42eb8caf6ce3fa3fea653539908ce77a01b80380 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 10:59:51 -0500 Subject: [PATCH 152/212] hard stops on refi/index --- public/content/translations/pt/refi/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/translations/pt/refi/index.md b/public/content/translations/pt/refi/index.md index 95dc4ae7cab..f9e5a4517b7 100644 --- a/public/content/translations/pt/refi/index.md +++ b/public/content/translations/pt/refi/index.md @@ -22,7 +22,7 @@ Um dos princípios das ReFi é o conceito de economia regenerativa criada por Jo ![Oito princípios interligados](refi-regenerative-economy-diagram.png) -Os projetos ReFi concretizam estes princípios usando [contratos inteligentes](/glossary/#smart-contract) e aplicações baseadas em [finanças descentralizadas (DeFi) ](/glossary/#defi) para incentivar comportamentos regenerativos, e.g. restaurar ecossistemas degradados e facilitar colaboração a larga escala em problemas globais como alterações climáticas ou perda de biodiversidade. +Os projetos ReFi concretizam estes princípios usando [contratos inteligentes](/glossary/#smart-contract) e aplicações baseadas em [finanças descentralizadas (DeFi) ](/glossary/#defi) para incentivar comportamentos regenerativos, e.g., restaurar ecossistemas degradados e facilitar colaboração a larga escala em problemas globais como alterações climáticas ou perda de biodiversidade. ReFi também se intersecta com o movimento de [ciência descentralizada (DeSci)](/desci/), que usa Ethereum como plataforma para financiar, criar, armazenar e divulgar conhecimento cientifico. As ferramentas DeSci podem eventualmente ser úteis para desenvolver normas e práticas verificáveis para implementar e monitorizar atividades regenerativas como, plantação de árvores, remoção de plástico do oceano ou o restauro de uma ecossistema degradado. @@ -32,7 +32,7 @@ ReFi também se intersecta com o movimento de [ciência descentralizada (DeSci)] O **[ mercado voluntário de carbono (MVC)](https://climatefocus.com/so-what-voluntary-carbon-market-exactly/)** é um mecanismo para financiar projetos que têm um impacto positivo verificado nas emissões de carbono, seja reduzindo a quantidade atual de emissões, ou removendo gases responsáveis pelo efeito estufa da atmosfera. Estes projetos recebem um ativo chamado "crédito de carbono" após serem verificados, que podem vender a individuos e organizações que querem apoiar ações contra as alterações climáticas. -Além do VCM, existem também vários mercados de carbono governamentais ("mercados regulados") que visam estabelecer um preço ao carbono mediante leis ou regulações com uma jurisdição específica (e.g. pais ou região), controlando a emissão de licenças a serem distribuídas. Os mercados regulados incentivam os poluidores sob a sua jurisdição a reduzir emissões, mas não conseguem remover os gases responsáveis pelo efeito de estufa que já foram emitidos. +Além do VCM, existem também vários mercados de carbono governamentais ("mercados regulados") que visam estabelecer um preço ao carbono mediante leis ou regulações com uma jurisdição específica (e.g., pais ou região), controlando a emissão de licenças a serem distribuídas. Os mercados regulados incentivam os poluidores sob a sua jurisdição a reduzir emissões, mas não conseguem remover os gases responsáveis pelo efeito de estufa que já foram emitidos. Apesar do seu desenvolvimento ao longo das mais recentes décadas, o VCM continua a sofrer com vários problemas: From 5d59ad28ad9330f54b1c5adf326cd38644529896 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:00:10 -0500 Subject: [PATCH 153/212] hard stops on pools/index --- public/content/translations/pl/staking/pools/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pl/staking/pools/index.md b/public/content/translations/pl/staking/pools/index.md index 2569058cbf2..3b1cbdbeaaf 100644 --- a/public/content/translations/pl/staking/pools/index.md +++ b/public/content/translations/pl/staking/pools/index.md @@ -26,7 +26,7 @@ Oprócz korzyści, które opisaliśmy w naszym [wprowadzeniu do stakingu](/staki - + From 0aa58884e14c17750909195f2b56f4a96b4549d2 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:00:51 -0500 Subject: [PATCH 154/212] hard stops on staking/pools/index --- public/content/translations/pcm/staking/pools/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pcm/staking/pools/index.md b/public/content/translations/pcm/staking/pools/index.md index 6b591bfdfe7..5e0aa98a638 100644 --- a/public/content/translations/pcm/staking/pools/index.md +++ b/public/content/translations/pcm/staking/pools/index.md @@ -26,7 +26,7 @@ In addishon to di benefits wi outline for waw [intro to staking](/staking/), to - + From c9110f0e1196dc243a353b7289fc98b4cdde4d55 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:01:33 -0500 Subject: [PATCH 155/212] hard stops pcm/security/index --- public/content/translations/pcm/security/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pcm/security/index.md b/public/content/translations/pcm/security/index.md index 8c07699a67e..063bb9e6980 100644 --- a/public/content/translations/pcm/security/index.md +++ b/public/content/translations/pcm/security/index.md @@ -104,7 +104,7 @@ One high-profile vashon of di don hapun in July 2020, wen dem don hack Twitter a Di celeb awoof na anoda komon form wey di skam awoof dey take. Di skammas go take one fidio intaview abi konfrens tok wey dem rekod and go put am for YouTube - as dem make am look laik di sey dem give one live fidio intaview to di seleb wia em dey apruf cryptocurrency awoof. -Dem yus Vitalik Buterin often in dis skam, but dem also yu plenti oda popular pipol involve in crypto (e.g. Elon Musk abi Charles Hoskinson). Pesin wey dem sabi wella join to give di skammas livestream sense of legitimasy (dis bi laik skam, but Vitalik join, so im suppose dey okay!). +Dem yus Vitalik Buterin often in dis skam, but dem also yu plenti oda popular pipol involve in crypto (e.g., Elon Musk abi Charles Hoskinson). Pesin wey dem sabi wella join to give di skammas livestream sense of legitimasy (dis bi laik skam, but Vitalik join, so im suppose dey okay!). **Awoof na always skams. If yu dey send yor funds to dis akants, yu go luz dem foreva.** From a94ebee5a92a3f46837f59dadfd2b8e42035452c Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:01:52 -0500 Subject: [PATCH 156/212] hard stops on pcm/nft/index --- public/content/translations/pcm/nft/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pcm/nft/index.md b/public/content/translations/pcm/nft/index.md index ace047e136b..7def1d8c959 100644 --- a/public/content/translations/pcm/nft/index.md +++ b/public/content/translations/pcm/nft/index.md @@ -52,7 +52,7 @@ Dem dey yus NFTs for many tins, wey inklude: - e dey for desentralize intanet domain names - kollateral inside [disentralized finans](/glossary/#defi) -E fit bi say yu bi artist wey wont shia dem work wey dey yus NFTs, witout luzin kontrol and sakrifisin yor profits to intamediaris. Yu fit kreate new kontrat and spesify di nomba of NFTs, dem propatis, and one link to some spesifik artwork. As di artist, ** yu fit program am inside di smart kontract di royaltis** wey dem suppose pay yu (e.g. transfa 5% of hau much dem sell NFT to di pesin wey get di kontract efri taim wey dem sell yor NFT). Yu fit also always pruf say yu don kreate di NFT bikos yu go own di [wallet](/glossary/#wallet) wey deploy di kontract. Pipol wey dey buy fit pruf sey dem own one **orijina NFT** from yor koleshon bikos dem wallet [address](/glossary/#address) dey konet wit one token inside yor smart kontract. Dem fit yus am akross di Ethereum ekosystem, konfidnet in im authentisity. +E fit bi say yu bi artist wey wont shia dem work wey dey yus NFTs, witout luzin kontrol and sakrifisin yor profits to intamediaris. Yu fit kreate new kontrat and spesify di nomba of NFTs, dem propatis, and one link to some spesifik artwork. As di artist, ** yu fit program am inside di smart kontract di royaltis** wey dem suppose pay yu (e.g., transfa 5% of hau much dem sell NFT to di pesin wey get di kontract efri taim wey dem sell yor NFT). Yu fit also always pruf say yu don kreate di NFT bikos yu go own di [wallet](/glossary/#wallet) wey deploy di kontract. Pipol wey dey buy fit pruf sey dem own one **orijina NFT** from yor koleshon bikos dem wallet [address](/glossary/#address) dey konet wit one token inside yor smart kontract. Dem fit yus am akross di Ethereum ekosystem, konfidnet in im authentisity.
Eksplore, buy abi kreate yor own NFT art/kolectibols...
From 605e522128c37cc5dd5d66237edbf463b5e4589f Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:02:36 -0500 Subject: [PATCH 157/212] hard stops on pcm/governance/index --- public/content/translations/pcm/governance/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/translations/pcm/governance/index.md b/public/content/translations/pcm/governance/index.md index 1cf91fce2cd..7ae5e6866ff 100644 --- a/public/content/translations/pcm/governance/index.md +++ b/public/content/translations/pcm/governance/index.md @@ -44,13 +44,13 @@ Plenti stakeholdas dey for [Ethereum komunity](/community/), wey ish dey play on - **ETher holdas**: dis pipol hold one arbitary amount of ETH. [More tok ETH](/eth/). - **Aplikashon Users**: dis pipol dey interact wit aplikashon on di Ethereum blockchain. -- **Aplikashon/Tooling Divelopas**: dis pipol dey write aplikashons wey dey run ontop di Ethereum blockchain (e.g. DeFi, NFTs, etc.) dem dey also build tooling wey pipol fit yus wit Ethereum (e.g. wallets, test suites, etc.). [More on dapps](/apps/). +- **Aplikashon/Tooling Divelopas**: dis pipol dey write aplikashons wey dey run ontop di Ethereum blockchain (e.g., DeFi, NFTs, etc.) dem dey also build tooling wey pipol fit yus wit Ethereum (e.g., wallets, test suites, etc.). [More on dapps](/apps/). - **Pipol wey dey operate Node**: dis pipol dey run nodes wey dey propagate blocks and transakshons, di node dey also reject any transakshon abi block wey nor koret wey dem kome akross. [More on nodes](/developers/docs/nodes-and-clients/). - **EIP Authors**: na dis pipol dey propose shanjis to di Ethereum protokol, in di form of Ethereum Imprufment Proposals (EIPs). [More on EIPs](/eips/). - **Validators**: na dis pipol dey run nodes wey fit add new blocks to di Ethereum blockchain. -- **Protokol Divelopas** (a.k.a. "Kore Divelopas"): dis pipol dey maintain di varios Ethereum implimentashons (e.g. go-ethereum, Nethermind, Besu, Erigon, Reth at di exekushon layer abi Prysm, Lighthouse, Nimbus, Teku, Lodestar, Grandie at di konsensus layer). [More on Ethereum klients](/developers/docs/nodes-and-clients/). +- **Protokol Divelopas** (a.k.a. "Kore Divelopas"): dis pipol dey maintain di varios Ethereum implimentashons (e.g., go-ethereum, Nethermind, Besu, Erigon, Reth at di exekushon layer abi Prysm, Lighthouse, Nimbus, Teku, Lodestar, Grandie at di konsensus layer). [More on Ethereum klients](/developers/docs/nodes-and-clients/). -_Notes: any individual fit bi part of plenti groups (e.g. one protokol divelopa fit shampion one EIP, and run one beakon chain validator, and yus DeFi aplikashons). For konsepshual klarity, im izy pass to distinguish bitwin dem, doh._ +_Notes: any individual fit bi part of plenti groups (e.g., one protokol divelopa fit shampion one EIP, and run one beakon chain validator, and yus DeFi aplikashons). For konsepshual klarity, im izy pass to distinguish bitwin dem, doh._ @@ -102,7 +102,7 @@ As some EIPs bit diret teknika imprufment wit smoll palava, some dey komplex and E no get playbook wey we fit follow to take handle proposals wey no go cause gbege. Dis na one rizut of Ethereum disentralize disihn wia nor singol stakeholda group fit yus forse on oda thru brute forse: protokol divelopas fit shuse make im nor impliment kode shanjis; node operators fit nor shuse to run di latest Ethereum klient; aplikashon teams and users fit nor shuse to transact on di chain. Sinse Protokol Divelopas nor get way to forse pipol to adopt netwok upgrades, dem go generaly afoid to dey impliment EIPs wia di kontenshiosnes pass di benefits to di broada komunity. -Dem ekspet EIP Shampions to solicit feedbak from all relivant stakeholdas. If yu find yorsef di shampion of one kontenshios EIP, yu supose try and address objeshons to build konsensus around yor EIP. Bikos di siza and divasity of di Ethereum komunity, nor singol metrik (e.g. one koin vote) dem fit yus dat to gauge komunity konsensus, and ekspet EIP Shampions to adapt to di situashon of dem proposal. +Dem ekspet EIP Shampions to solicit feedbak from all relivant stakeholdas. If yu find yorsef di shampion of one kontenshios EIP, yu supose try and address objeshons to build konsensus around yor EIP. Bikos di siza and divasity of di Ethereum komunity, nor singol metrik (e.g., one koin vote) dem fit yus dat to gauge komunity konsensus, and ekspet EIP Shampions to adapt to di situashon of dem proposal. Biyond di sekurity of di Ethereum netwok, signifikant weight dey on Protokol Divelopas on wetin Aplikashon/Tooling Divelopas and Aplikashon Users value, bikos dem dey yus and dey divelop on Ethereum make dem atrative for oda stakeholdas. Also, wi nid impliment EIPs akross all klient implimentashons, and difren teams dey manaj ish of dis klients. Part of dis process ushualy mean to dey konvins plenti teams of Protokol Divelopas sey one patikular shanj get value and im dey helep end-users abi solve one sekurity issue. From c379dad1b346c439a65ba9ebb62712c891a94ca6 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:03:19 -0500 Subject: [PATCH 158/212] hard stops on staking/pools/index --- public/content/translations/nl/staking/pools/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/nl/staking/pools/index.md b/public/content/translations/nl/staking/pools/index.md index 69d60d8a5d7..3580fd0cce9 100644 --- a/public/content/translations/nl/staking/pools/index.md +++ b/public/content/translations/nl/staking/pools/index.md @@ -26,7 +26,7 @@ Naast de voordelen die we hebben behandeld in onze [inleiding tot staking](/stak - + From fa2e1fa6dd0272b41b8afdefcf6cb17335972cd4 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:04:03 -0500 Subject: [PATCH 159/212] hard stops on staking/pools/index --- public/content/translations/ja/staking/pools/index.md | 2 +- public/content/translations/ko/staking/pools/index.md | 2 +- public/content/translations/ms/staking/pools/index.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/translations/ja/staking/pools/index.md b/public/content/translations/ja/staking/pools/index.md index ff0c2aca26c..6da4e765ead 100644 --- a/public/content/translations/ja/staking/pools/index.md +++ b/public/content/translations/ja/staking/pools/index.md @@ -26,7 +26,7 @@ summaryPoints: - + diff --git a/public/content/translations/ko/staking/pools/index.md b/public/content/translations/ko/staking/pools/index.md index 5885e79d8b4..d2b42f94646 100644 --- a/public/content/translations/ko/staking/pools/index.md +++ b/public/content/translations/ko/staking/pools/index.md @@ -26,7 +26,7 @@ summaryPoints: - + diff --git a/public/content/translations/ms/staking/pools/index.md b/public/content/translations/ms/staking/pools/index.md index a4ca60c2b01..518145d54a9 100644 --- a/public/content/translations/ms/staking/pools/index.md +++ b/public/content/translations/ms/staking/pools/index.md @@ -26,7 +26,7 @@ Di samping faedah yang kami gariskan dalam [pengenalan kepada pertaruhan](/staki - + From 1fe983e263b5ff01cf9a16fb3cf670d2680488d5 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:04:35 -0500 Subject: [PATCH 160/212] hard stops on optimism-std-bridge-annotated-code/index --- .../tutorials/optimism-std-bridge-annotated-code/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ja/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/ja/developers/tutorials/optimism-std-bridge-annotated-code/index.md index 061558e6078..d1b9c3ffae4 100644 --- a/public/content/translations/ja/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/translations/ja/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -725,7 +725,7 @@ contract L1StandardBridge is IL1StandardBridge, CrossDomainEnabled { ```solidity /** * @dev Performs the logic for deposits by informing the L2 Deposited Token - * contract of the deposit and calling a handler to lock the L1 funds. (e.g. transferFrom) + * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom) * * @param _l1Token Address of the L1 ERC20 we are depositing * @param _l2Token Address of the L1 respective L2 ERC20 From b7b4a91bdd3417cc12ff6a8f13268d085f9c5a85 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:05:09 -0500 Subject: [PATCH 161/212] hard stops on nft-minter/index --- .../ja/developers/tutorials/nft-minter/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/translations/ja/developers/tutorials/nft-minter/index.md b/public/content/translations/ja/developers/tutorials/nft-minter/index.md index 99fe6eb2a9f..b54dc60b215 100644 --- a/public/content/translations/ja/developers/tutorials/nft-minter/index.md +++ b/public/content/translations/ja/developers/tutorials/nft-minter/index.md @@ -163,19 +163,19 @@ return (

🖼 Link to asset:

setURL(event.target.value)} />

🤔 Name:

setName(event.target.value)} />

✍️ Description:

setDescription(event.target.value)} /> From 1e7b23403509e732399bc7167dd0067b4cae0c3e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:05:38 -0500 Subject: [PATCH 162/212] hard stops on erc20-annotated-code/index --- .../ja/developers/tutorials/erc20-annotated-code/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/translations/ja/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/ja/developers/tutorials/erc20-annotated-code/index.md index a4d3b011fc9..39eef399f04 100644 --- a/public/content/translations/ja/developers/tutorials/erc20-annotated-code/index.md +++ b/public/content/translations/ja/developers/tutorials/erc20-annotated-code/index.md @@ -594,7 +594,7 @@ B: * @dev Moves tokens `amount` from `sender` to `recipient`. * * This is internal function is equivalent to {transfer}, and can be used to - * e.g. implement automatic token fees, slashing mechanisms, etc. + * e.g., implement automatic token fees, slashing mechanisms, etc. * * Emits a {Transfer} event. * @@ -715,7 +715,7 @@ OpenZeppelin ERC-20のコードはすでに監査を受けており、安全で * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens. * * This internal function is equivalent to `approve`, and can be used to - * e.g. set automatic allowances for certain subsystems, etc. + * e.g., set automatic allowances for certain subsystems, etc. * * Emits an {Approval} event. * From 61e911fa3322d0a0e736762420aa9719f3e1704e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:06:03 -0500 Subject: [PATCH 163/212] hard stops on staking/pools/index --- public/content/translations/it/staking/pools/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/it/staking/pools/index.md b/public/content/translations/it/staking/pools/index.md index e25d353d665..6062d36558e 100644 --- a/public/content/translations/it/staking/pools/index.md +++ b/public/content/translations/it/staking/pools/index.md @@ -26,7 +26,7 @@ Oltre ai vantaggi che abbiamo delineato nella nostra [introduzione allo staking] - + From 0c8efbb083237e404ce362d2b55c12d5b084e326 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:06:32 -0500 Subject: [PATCH 164/212] hard stops on optimism-std-bridge-annotated-code/index --- .../tutorials/optimism-std-bridge-annotated-code/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/it/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/it/developers/tutorials/optimism-std-bridge-annotated-code/index.md index 2633b9a5da7..623a368b33e 100644 --- a/public/content/translations/it/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/translations/it/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -725,7 +725,7 @@ Queste due funzioni sono wrapper intorno a `_initiateERC20Deposit`, la funzione ```solidity /** * @dev Performs the logic for deposits by informing the L2 Deposited Token - * contract of the deposit and calling a handler to lock the L1 funds. (e.g. transferFrom) + * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom) * * @param _l1Token Address of the L1 ERC20 we are depositing * @param _l2Token Address of the L1 respective L2 ERC20 From 8cb102c9c7be6c138786c4c9a4722c026a884879 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:06:56 -0500 Subject: [PATCH 165/212] hard stops on nft-minter/index --- .../it/developers/tutorials/nft-minter/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/translations/it/developers/tutorials/nft-minter/index.md b/public/content/translations/it/developers/tutorials/nft-minter/index.md index 1171601bf02..5029f29175f 100644 --- a/public/content/translations/it/developers/tutorials/nft-minter/index.md +++ b/public/content/translations/it/developers/tutorials/nft-minter/index.md @@ -163,19 +163,19 @@ return (

🖼 Link to asset:

setURL(event.target.value)} />

🤔 Name:

setName(event.target.value)} />

✍️ Description:

setDescription(event.target.value)} /> From 350cebc8b1b9ad2347b80b8e17c0bd59cfdf7834 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:15:36 -0500 Subject: [PATCH 166/212] hard stops on staking/pools/index --- public/content/staking/pools/index.md | 2 +- public/content/translations/ar/staking/pools/index.md | 2 +- public/content/translations/bn/staking/pools/index.md | 2 +- public/content/translations/cs/staking/pools/index.md | 2 +- public/content/translations/de/staking/pools/index.md | 2 +- public/content/translations/el/staking/pools/index.md | 2 +- public/content/translations/es/staking/pools/index.md | 2 +- public/content/translations/fa/staking/pools/index.md | 2 +- public/content/translations/fil/staking/pools/index.md | 2 +- public/content/translations/fr/staking/pools/index.md | 2 +- public/content/translations/ga/staking/pools/index.md | 2 +- public/content/translations/ha/staking/pools/index.md | 2 +- public/content/translations/hi/staking/pools/index.md | 2 +- public/content/translations/hu/staking/pools/index.md | 2 +- public/content/translations/id/staking/pools/index.md | 2 +- 15 files changed, 15 insertions(+), 15 deletions(-) diff --git a/public/content/staking/pools/index.md b/public/content/staking/pools/index.md index e7cdc71ea71..9e586c27a8d 100644 --- a/public/content/staking/pools/index.md +++ b/public/content/staking/pools/index.md @@ -26,7 +26,7 @@ In addition to the benefits we outlined in our [intro to staking](/staking/), st - + diff --git a/public/content/translations/ar/staking/pools/index.md b/public/content/translations/ar/staking/pools/index.md index ed622f30c1a..0e380733428 100644 --- a/public/content/translations/ar/staking/pools/index.md +++ b/public/content/translations/ar/staking/pools/index.md @@ -26,7 +26,7 @@ summaryPoints: - + diff --git a/public/content/translations/bn/staking/pools/index.md b/public/content/translations/bn/staking/pools/index.md index e3a06852bea..dbdcc79de90 100644 --- a/public/content/translations/bn/staking/pools/index.md +++ b/public/content/translations/bn/staking/pools/index.md @@ -26,7 +26,7 @@ summaryPoints: - + diff --git a/public/content/translations/cs/staking/pools/index.md b/public/content/translations/cs/staking/pools/index.md index f7f39d35f56..6d9a1ba3a88 100644 --- a/public/content/translations/cs/staking/pools/index.md +++ b/public/content/translations/cs/staking/pools/index.md @@ -26,7 +26,7 @@ Kromě výhod, které jsme nastínili v našem [úvodu do vkládání](/staking/ - + diff --git a/public/content/translations/de/staking/pools/index.md b/public/content/translations/de/staking/pools/index.md index 2fc6840e73e..2a84f857034 100644 --- a/public/content/translations/de/staking/pools/index.md +++ b/public/content/translations/de/staking/pools/index.md @@ -26,7 +26,7 @@ Zusätzlich zu den Vorteilen, die wir in unserer [Einführung zum Staking](/stak - + diff --git a/public/content/translations/el/staking/pools/index.md b/public/content/translations/el/staking/pools/index.md index 4b1c6cd3384..231fba0f976 100644 --- a/public/content/translations/el/staking/pools/index.md +++ b/public/content/translations/el/staking/pools/index.md @@ -26,7 +26,7 @@ summaryPoints: - + diff --git a/public/content/translations/es/staking/pools/index.md b/public/content/translations/es/staking/pools/index.md index 5f599d1d2c4..d3d63474c89 100644 --- a/public/content/translations/es/staking/pools/index.md +++ b/public/content/translations/es/staking/pools/index.md @@ -26,7 +26,7 @@ Además de las ventajas que hemos descrito en nuestra [introducción a las parti - + diff --git a/public/content/translations/fa/staking/pools/index.md b/public/content/translations/fa/staking/pools/index.md index 7436b3f3c8d..557d9233bcd 100644 --- a/public/content/translations/fa/staking/pools/index.md +++ b/public/content/translations/fa/staking/pools/index.md @@ -26,7 +26,7 @@ summaryPoints: - + diff --git a/public/content/translations/fil/staking/pools/index.md b/public/content/translations/fil/staking/pools/index.md index 57253bb15ac..22f24418e0a 100644 --- a/public/content/translations/fil/staking/pools/index.md +++ b/public/content/translations/fil/staking/pools/index.md @@ -26,7 +26,7 @@ Bukod sa mga benepisyo na aming inilahad sa aming [panimula sa staking](/staking - + diff --git a/public/content/translations/fr/staking/pools/index.md b/public/content/translations/fr/staking/pools/index.md index 11612bae7a8..263b4a599cd 100644 --- a/public/content/translations/fr/staking/pools/index.md +++ b/public/content/translations/fr/staking/pools/index.md @@ -26,7 +26,7 @@ En plus des avantages que nous avons décrits dans notre [introduction à la mis - + diff --git a/public/content/translations/ga/staking/pools/index.md b/public/content/translations/ga/staking/pools/index.md index 67ced518881..3a8e9d79ba2 100644 --- a/public/content/translations/ga/staking/pools/index.md +++ b/public/content/translations/ga/staking/pools/index.md @@ -26,7 +26,7 @@ Chomh maith leis na buntáistí a leagamar amach inár [réamhrá ar gheall](/st - + diff --git a/public/content/translations/ha/staking/pools/index.md b/public/content/translations/ha/staking/pools/index.md index 009d1cf835d..d42176ebdde 100644 --- a/public/content/translations/ha/staking/pools/index.md +++ b/public/content/translations/ha/staking/pools/index.md @@ -26,7 +26,7 @@ Wasu tafkan suna aiki ta amfani da kwangila masu wayo, inda za a iya saka kuɗi - + diff --git a/public/content/translations/hi/staking/pools/index.md b/public/content/translations/hi/staking/pools/index.md index fb045218680..0824bf5bd26 100644 --- a/public/content/translations/hi/staking/pools/index.md +++ b/public/content/translations/hi/staking/pools/index.md @@ -26,7 +26,7 @@ summaryPoints: - + diff --git a/public/content/translations/hu/staking/pools/index.md b/public/content/translations/hu/staking/pools/index.md index 42389afe957..71a858d4c47 100644 --- a/public/content/translations/hu/staking/pools/index.md +++ b/public/content/translations/hu/staking/pools/index.md @@ -26,7 +26,7 @@ A [bevezetés a letétbe helyezésbe](/staking/) során elhangzott előnyök mel - + diff --git a/public/content/translations/id/staking/pools/index.md b/public/content/translations/id/staking/pools/index.md index e7196724df1..99654f19c40 100644 --- a/public/content/translations/id/staking/pools/index.md +++ b/public/content/translations/id/staking/pools/index.md @@ -26,7 +26,7 @@ Selain manfaat yang kami sebutkan dalam [pengantar tentang penaruhan](/staking/) - + From e502b29677869cb7f8710ca0a58365144d6e0d80 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:16:10 -0500 Subject: [PATCH 167/212] hard stops on erc20-annotated-code/index --- .../es/developers/tutorials/erc20-annotated-code/index.md | 4 ++-- .../es/developers/tutorials/nft-minter/index.md | 6 +++--- .../tutorials/optimism-std-bridge-annotated-code/index.md | 2 +- .../fr/developers/tutorials/nft-minter/index.md | 6 +++--- .../tutorials/optimism-std-bridge-annotated-code/index.md | 2 +- .../pow/mining/mining-algorithms/ethash/index.md | 2 +- .../docs/design-and-ux/dex-design-best-practice/index.md | 2 +- .../developers/docs/nodes-and-clients/run-a-node/index.md | 6 +++--- public/content/translations/ga/refi/index.md | 2 +- .../content/translations/ga/zero-knowledge-proofs/index.md | 2 +- .../docs/nodes-and-clients/nodes-as-a-service/index.md | 4 ++-- .../guide-to-smart-contract-security-tools/index.md | 2 +- .../tutorials/how-to-use-tellor-as-your-oracle/index.md | 2 +- .../tutorials/optimism-std-bridge-annotated-code/index.md | 2 +- .../translations/it/developers/docs/storage/index.md | 2 +- .../it/developers/tutorials/erc20-annotated-code/index.md | 4 ++-- 16 files changed, 25 insertions(+), 25 deletions(-) diff --git a/public/content/translations/es/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/es/developers/tutorials/erc20-annotated-code/index.md index 040dc2bb9e0..d173e458546 100644 --- a/public/content/translations/es/developers/tutorials/erc20-annotated-code/index.md +++ b/public/content/translations/es/developers/tutorials/erc20-annotated-code/index.md @@ -594,7 +594,7 @@ Estas son las cuatro funciones que hacen el verdadero trabajo: `_transfer`, `_mi * @dev Moves tokens `amount` from `sender` to `recipient`. * * This is internal function is equivalent to {transfer}, and can be used to - * e.g. implement automatic token fees, slashing mechanisms, etc. + * e.g., implement automatic token fees, slashing mechanisms, etc. * * Emits a {Transfer} event. * @@ -715,7 +715,7 @@ Esta es la función que actualmente especifica asignaciones. Observe que esta pe * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens. * * This internal function is equivalent to `approve`, and can be used to - * e.g. set automatic allowances for certain subsystems, etc. + * e.g., set automatic allowances for certain subsystems, etc. * * Emits an {Approval} event. * diff --git a/public/content/translations/es/developers/tutorials/nft-minter/index.md b/public/content/translations/es/developers/tutorials/nft-minter/index.md index 1b1027b9352..59c0308ac77 100644 --- a/public/content/translations/es/developers/tutorials/nft-minter/index.md +++ b/public/content/translations/es/developers/tutorials/nft-minter/index.md @@ -163,19 +163,19 @@ return (

🖼 Link to asset:

setURL(event.target.value)} />

🤔 Name:

setName(event.target.value)} />

✍️ Description:

setDescription(event.target.value)} /> diff --git a/public/content/translations/es/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/es/developers/tutorials/optimism-std-bridge-annotated-code/index.md index 1ac98ad7779..6881d254219 100644 --- a/public/content/translations/es/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/translations/es/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -725,7 +725,7 @@ Estas dos funciones son wrappers alrededor de `_initiateERC20Deposit`, la funci ```solidity /** * @dev Performs the logic for deposits by informing the L2 Deposited Token - * contract of the deposit and calling a handler to lock the L1 funds. (e.g. transferFrom) + * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom) * * @param _l1Token Address of the L1 ERC20 we are depositing * @param _l2Token Address of the L1 respective L2 ERC20 diff --git a/public/content/translations/fr/developers/tutorials/nft-minter/index.md b/public/content/translations/fr/developers/tutorials/nft-minter/index.md index 3b6aacf4caa..3c99a06a073 100644 --- a/public/content/translations/fr/developers/tutorials/nft-minter/index.md +++ b/public/content/translations/fr/developers/tutorials/nft-minter/index.md @@ -163,19 +163,19 @@ return (

🖼 Link to asset:

setURL(event.target.value)} />

🤔 Name:

setName(event.target.value)} />

✍️ Description:

setDescription(event.target.value)} /> diff --git a/public/content/translations/fr/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/fr/developers/tutorials/optimism-std-bridge-annotated-code/index.md index ac53b339684..62c03df2159 100644 --- a/public/content/translations/fr/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/translations/fr/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -725,7 +725,7 @@ Ces deux fonctions sont enveloppées autour de `_initiateERC20Deposit`, la fonct ```solidity /** * @dev Performs the logic for deposits by informing the L2 Deposited Token - * contract of the deposit and calling a handler to lock the L1 funds. (e.g. transferFrom) + * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom) * * @param _l1Token Address of the L1 ERC20 we are depositing * @param _l2Token Address of the L1 respective L2 ERC20 diff --git a/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md index ff6e4e62b33..6831bcb78b0 100644 --- a/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md +++ b/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -44,7 +44,7 @@ ACCESSES = 64 # number of accesses in hashimoto loop ### Úsáid 'SHA3' {#sha3} -Tharla forbairt Ethereum ag an am céanna le forbairt an chaighdeáin SHA3, agus rinne an próiseas caighdeáin athrú déanach i stuáil an algartam haise críochnaithe, ionas nach haiseanna Ethereum caighdeánacha sha3 iad "sha3_256" agus "sha3_512", ach malairt ar a dtugtar "Keccak-256" agus "Keccak-512" go minic i gcomhthéacsanna eile. Féach plé, e.g. [anseo](https://eips.ethereum.org/EIPS/eip-1803), [anseo](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), nó [anseo](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). +Tharla forbairt Ethereum ag an am céanna le forbairt an chaighdeáin SHA3, agus rinne an próiseas caighdeáin athrú déanach i stuáil an algartam haise críochnaithe, ionas nach haiseanna Ethereum caighdeánacha sha3 iad "sha3_256" agus "sha3_512", ach malairt ar a dtugtar "Keccak-256" agus "Keccak-512" go minic i gcomhthéacsanna eile. Féach plé, e.g., [anseo](https://eips.ethereum.org/EIPS/eip-1803), [anseo](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), nó [anseo](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). Meabhraigh le do thoil go dtagraítear do haiseanna mar "sha3" san algartam thíos. diff --git a/public/content/translations/ga/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/ga/developers/docs/design-and-ux/dex-design-best-practice/index.md index c70829fb872..5b7284b21db 100644 --- a/public/content/translations/ga/developers/docs/design-and-ux/dex-design-best-practice/index.md +++ b/public/content/translations/ga/developers/docs/design-and-ux/dex-design-best-practice/index.md @@ -168,7 +168,7 @@ Is é an príomhrud ná gur dócha nach ndéanann sé difríocht mhór don inús Bhí sé suimiúil go leor an faisean a fheiceáil ag athrú le himeacht ama. Ar dtús bhí an comhartha ag Uniswap ar chlé, ach tá sé tar éis bogadh ar dheis ó shin. Rinne Sushiswap an t-athrú seo freisin le linn uasghrádú dearaidh. Lean formhór na bprótacal, ach ní iad léir, an nós seo. -Go traidisiúnta cuireann coinbhinsiún airgeadais an tsiombail airgeadra roimh an uimhir, e.g. $50, €50, £50, ach _deirimid_ 50 dollar, 50 Euro, 50 punt. +Go traidisiúnta cuireann coinbhinsiún airgeadais an tsiombail airgeadra roimh an uimhir, e.g., $50, €50, £50, ach _deirimid_ 50 dollar, 50 Euro, 50 punt. Don úsáideoir ginearálta - go háirithe duine a léann ó chlé go deas, ó bharr go bun - is dócha go mothaíonn comhartha ar dheis níos nádúrtha. diff --git a/public/content/translations/ga/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/translations/ga/developers/docs/nodes-and-clients/run-a-node/index.md index ef9fa3f2375..161c7330d16 100644 --- a/public/content/translations/ga/developers/docs/nodes-and-clients/run-a-node/index.md +++ b/public/content/translations/ga/developers/docs/nodes-and-clients/run-a-node/index.md @@ -191,7 +191,7 @@ Tar éis duit na bogearraí cliant a shuiteáil, a íoslódáil, nó a thiomsú, Tosaímid le roghanna ar féidir leo tionchar suntasach a imirt ar fheidhmíocht na gcliant agus ar úsáid sonraí. Léiríonn [ modhanna sioncronaithe](/developers/docs/nodes-and-clients/#sync-modes) modhanna éagsúla chun sonraí blocshlabhra a íoslódáil agus a bhailíochtú. Sula dtosaíonn tú an nód, ba cheart duit cinneadh a dhéanamh cén modh líonra agus sioncronaithe a úsáidfidh tú. Is iad na rudaí is tábhachtaí le breithniú ná an spás diosca, agus an t-am sioncronaithe a bheidh ag teastáil ón gcliant. Tabhair aird ar dhoiciméid an chliaint chun a chinneadh cén modh sioncronaithe atá réamhshocraithe. Mura n-oireann sin duit, roghnaigh ceann eile bunaithe ar an leibhéal slándála, na sonraí atá ar fáil, agus an costas. Seachas an t-algartam sioncrónaithe, is féidir leat prúnáil de chineálacha éagsúla sean-shonraí a shocrú freisin. Cumasaíonn prúnáil sonraí atá as dáta a scriosadh, m.sh. nóid trie stáit a bhaint nach féidir teacht orthu ó bhloic le déanaí. -Tá roghanna bunúsacha cumraíochta eile ann, e.g. roghnú líonra - Mainnet nó testnets, críochphointe HTTP do RPC nó WebSockets, srl a chumasú. Is féidir leat na gnéithe agus na roghanna go léir a fháil i ndoiciméadú an chliaint. Is féidir cumraíochtaí éagsúla cliant a shocrú tríd an gcliant a rith leis na bratacha comhfhreagracha go díreach sa chomhad CLI nó cumraíochta. Tá gach cliant beagán difriúil; déan tagairt i gcónaí dá cháipéisíocht oifigiúil nó dá leathanach cabhrach le haghaidh sonraí ar roghanna cumraíochta. +Tá roghanna bunúsacha cumraíochta eile ann, e.g., roghnú líonra - Mainnet nó testnets, críochphointe HTTP do RPC nó WebSockets, srl a chumasú. Is féidir leat na gnéithe agus na roghanna go léir a fháil i ndoiciméadú an chliaint. Is féidir cumraíochtaí éagsúla cliant a shocrú tríd an gcliant a rith leis na bratacha comhfhreagracha go díreach sa chomhad CLI nó cumraíochta. Tá gach cliant beagán difriúil; déan tagairt i gcónaí dá cháipéisíocht oifigiúil nó dá leathanach cabhrach le haghaidh sonraí ar roghanna cumraíochta. Chun críocha tástála, b'fhéidir gurbh fhearr leat cliant a rith ar cheann de na líonraí testnet. [Féach forbhreathnú ar líonraí tacaithe](/developers/docs/nodes-and-clients/#execution-clients). @@ -402,7 +402,7 @@ Tairgeann cliaint reatha [ críochphointí API RPC](/developers/docs/apis/json-r - Ag glaoch orthu de láimh le prótacal oiriúnach (m.sh. ag baint úsáide as `curl`) - Consól soláthraithe á cheangal (m.sh. `get attach`) -- Iad a chur i bhfeidhm in aon fheidhmchlár a úsáideann leabharlanna web3, e.g. [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview), [ethers](https://github.com/ethers-io /ethers.js/) +- Iad a chur i bhfeidhm in aon fheidhmchlár a úsáideann leabharlanna web3, e.g., [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview), [ethers](https://github.com/ethers-io /ethers.js/) Tá feidhmiúcháin éagsúla de chríochphointí RPC ag cliaint éagsúla. Ach tá JSON-RPC caighdeánach ann ar féidir leat a úsáid le gach cliant. Le haghaidh forbhreathnú [léigh na doiciméid JSON-RPC](/developers/docs/apis/json-rpc/). Is féidir le hiarratais a dteastaíonn faisnéis ó líonra Ethereum uathu an RPC seo a úsáid. Mar shampla, ligeann sparán móréilimh MetaMask duit [nascadh le do chríochphointe RPC féin](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node) a bhfuil buntáistí láidre príobháideachta agus slándála aige. @@ -440,7 +440,7 @@ _Ní bhaineann sé seo le nóid bhailíochtóirí ciseal comhdhearcaidh._ Má th #### Seirbhísí cliant a chruthú {#creating-client-services} -Smaoinigh ar sheirbhís a chruthú chun do chliaint a rith go huathoibríoch agus iad ag am tosaithe. Mar shampla, ar fhreastalaithe Linux, bheadh ​​dea-chleachtas ann seirbhís a chruthú, e.g. le `systemd`, a fheidhmíonn an cliant le cumraíocht chuí, faoi úsáideoir le pribhléidí teoranta agus a atosaíonn go huathoibríoch. +Smaoinigh ar sheirbhís a chruthú chun do chliaint a rith go huathoibríoch agus iad ag am tosaithe. Mar shampla, ar fhreastalaithe Linux, bheadh ​​dea-chleachtas ann seirbhís a chruthú, e.g., le `systemd`, a fheidhmíonn an cliant le cumraíocht chuí, faoi úsáideoir le pribhléidí teoranta agus a atosaíonn go huathoibríoch. #### Cliaint á nuashonrú {#updating-clients} diff --git a/public/content/translations/ga/refi/index.md b/public/content/translations/ga/refi/index.md index edc5a62e269..d6dc1c44db9 100644 --- a/public/content/translations/ga/refi/index.md +++ b/public/content/translations/ga/refi/index.md @@ -22,7 +22,7 @@ Ar cheann de bhunsraitheanna ReFi tá coincheap na heacnamaíochta athghiniúna ![Ocht bprionsabal idirnasctha](refi-regenerative-economy-diagram.png) -Comhlíonann tionscadail ReFi na prionsabail seo trí úsáid a bhaint as [conarthaí cliste](/glossary/#smart-contract) agus [airgeadas díláraithe (DeFi)](/glossary/#defi) chun iompraíochtaí athghiniúna a dhreasú, e.g. éiceachórais dhíghrádaithe a athchóiriú agus comhoibriú ar scála mór a éascú ar shaincheisteanna domhanda amhail athrú aeráide agus caillteanas bithéagsúlachta. +Comhlíonann tionscadail ReFi na prionsabail seo trí úsáid a bhaint as [conarthaí cliste](/glossary/#smart-contract) agus [airgeadas díláraithe (DeFi)](/glossary/#defi) chun iompraíochtaí athghiniúna a dhreasú, e.g., éiceachórais dhíghrádaithe a athchóiriú agus comhoibriú ar scála mór a éascú ar shaincheisteanna domhanda amhail athrú aeráide agus caillteanas bithéagsúlachta. Forluíonn ReFi freisin leis an ngluaiseacht um [eolaíocht dhíláraithe (DeSci)](/desci/), a úsáideann Ethereum mar ardán chun eolas eolaíoch a mhaoiniú, a chruthú, a athbhreithniú, a chreidmheas, a stóráil agus a scaipeadh. D’fhéadfadh uirlisí DeSci a bheith úsáideach chun caighdeáin agus cleachtais infhíoraithe a fhorbairt chun gníomhaíochtaí athghiniúna a chur chun feidhme agus chun monatóireacht a dhéanamh orthu amhail crainn a chur, plaisteach a bhaint den aigéan nó éiceachóras díghrádaithe a athchóiriú. diff --git a/public/content/translations/ga/zero-knowledge-proofs/index.md b/public/content/translations/ga/zero-knowledge-proofs/index.md index a864667bccc..449f8e2ecd9 100644 --- a/public/content/translations/ga/zero-knowledge-proofs/index.md +++ b/public/content/translations/ga/zero-knowledge-proofs/index.md @@ -32,7 +32,7 @@ Ag dul ar ais chuig ár sampla níos luaithe, is é an t-aon fhianaise atá uait Is minic a bhíonn íocaíochtaí le cárta creidmheasa le feiceáil ag an iomad páirtí, lena n-áirítear an soláthraí íocaíochtaí, bainc agus páirtithe leasmhara eile (m.sh., údaráis rialtais). Cé go bhfuil buntáistí ag faireachas airgeadais chun gníomhaíocht mhídhleathach a shainaithint, baineann sé an bonn de phríobháideachas na ngnáthshaoránach freisin. -Bhí sé mar aidhm ag cripte-airgeadraí bealach a sholáthar d'úsáideoirí chun idirbhearta príobháideacha, piaraí le piaraí a dhéanamh. Ach tá formhór na n-idirbheart criptea-airgeadraí le feiceáil go hoscailte ar bhlocshlabhra poiblí. User identities are often pseudonymous and either wilfully linked to real-world identities (e.g. by including ETH addresses on Twitter or GitHub profiles) or can be associated with real-world identities using basic on and offchain data analysis. +Bhí sé mar aidhm ag cripte-airgeadraí bealach a sholáthar d'úsáideoirí chun idirbhearta príobháideacha, piaraí le piaraí a dhéanamh. Ach tá formhór na n-idirbheart criptea-airgeadraí le feiceáil go hoscailte ar bhlocshlabhra poiblí. User identities are often pseudonymous and either wilfully linked to real-world identities (e.g., by including ETH addresses on Twitter or GitHub profiles) or can be associated with real-world identities using basic on and offchain data analysis. Tá “boinn phríobháideachais” ar leith ann atá deartha le haghaidh idirbhearta go hiomlán gan ainm. Trí bhlocshlabhraí atá dírithe ar phríobháideacht, mar shampla Zcash agus Monero, tugtar cosaint do shonraí idirbhirt, lena n-áirítear seoltaí seoltóra/glacadóir, cineál sócmhainne, cainníocht agus amlíne an idirbhirt. diff --git a/public/content/translations/id/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/translations/id/developers/docs/nodes-and-clients/nodes-as-a-service/index.md index dccbf7eb231..2418386045f 100644 --- a/public/content/translations/id/developers/docs/nodes-and-clients/nodes-as-a-service/index.md +++ b/public/content/translations/id/developers/docs/nodes-and-clients/nodes-as-a-service/index.md @@ -123,14 +123,14 @@ Berikut ini adalah daftar beberapa penyedia node Ethereum paling populer, jangan - 500+ administrative and service APIs - RESTful interface for Ethereum transaction submission (Apache Kafka backed) - Outbound streams for event delivery (Apache Kafka backed) - - Deep collection of "off-chain" and ancillary services (e.g. bilateral encrypted messaging transport) + - Deep collection of "off-chain" and ancillary services (e.g., bilateral encrypted messaging transport) - Straightforward network onboarding with governance and role-based access control - Sophisticated user management for both administrators and end users - Highly scalable, resilient, enterprise-grade infrastructure - Cloud HSM private key management - Ethereum Mainnet Tethering - ISO 27k and SOC 2, Type 2 certifications - - Dynamic runtime configuration (e.g. adding cloud integrations, altering node ingresses, etc.) + - Dynamic runtime configuration (e.g., adding cloud integrations, altering node ingresses, etc.) - Support for multi-cloud, multi-region and hybrid deployment orchestrations - Simple hourly SaaS-based pricing - SLAs and 24x7 support diff --git a/public/content/translations/id/developers/tutorials/guide-to-smart-contract-security-tools/index.md b/public/content/translations/id/developers/tutorials/guide-to-smart-contract-security-tools/index.md index 8159a9f0e05..4d10fc632df 100644 --- a/public/content/translations/id/developers/tutorials/guide-to-smart-contract-security-tools/index.md +++ b/public/content/translations/id/developers/tutorials/guide-to-smart-contract-security-tools/index.md @@ -67,7 +67,7 @@ Area luas yang sering kali relevan untuk kontrak pintar mencakup: - Echidna dan Manticore adalah peralatan yang lebih disarankan untuk menguji spesifikasi mesin state. -- **Access controls.** If your system has privileged users (e.g. an owner, controllers, ...) you must ensure that (1) each user can only perform the authorized actions and (2) no user can block actions from a more privileged user. +- **Access controls.** If your system has privileged users (e.g., an owner, controllers, ...) you must ensure that (1) each user can only perform the authorized actions and (2) no user can block actions from a more privileged user. - Slither, Echidna, dan Manticore dapat memeriksa kontrol akses yang benar. Sebagai contoh, Slither dapat memeriksa bahwa hanya fungsi yang masuk dalam daftar putih yang tidak memiliki modifier onlyOwner. Echidna dan Manticore berguna untuk kontrol akses yang lebih kompleks, seperti izin yang diberikan hanya jika kontrak mencapai state yang diberikan. diff --git a/public/content/translations/id/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md b/public/content/translations/id/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md index 4d4c86b6409..43eee51cfb2 100644 --- a/public/content/translations/id/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md +++ b/public/content/translations/id/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md @@ -30,7 +30,7 @@ Tellor adalah oracle sumber terbuka dan langsung yang siap untuk diimplementasik ## Gambaran umum {#overview} -Tellor is an oracle system where parties can request the value of an off-chain data point (e.g. BTC/USD) and reporters compete to add this value to an on-chain data-bank, accessible by all Ethereum smart contracts. The inputs to this data-bank are secured by a network of staked reporters. Tellor utilizes crypto-economic incentive mechanisms, rewarding honest data submissions by reporters and punishing bad actors through the issuance of Tellor’s token, Tributes (TRB) and a dispute mechanism. +Tellor is an oracle system where parties can request the value of an off-chain data point (e.g., BTC/USD) and reporters compete to add this value to an on-chain data-bank, accessible by all Ethereum smart contracts. The inputs to this data-bank are secured by a network of staked reporters. Tellor utilizes crypto-economic incentive mechanisms, rewarding honest data submissions by reporters and punishing bad actors through the issuance of Tellor’s token, Tributes (TRB) and a dispute mechanism. Dalam tutorial ini, kita akan membahas: diff --git a/public/content/translations/id/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/translations/id/developers/tutorials/optimism-std-bridge-annotated-code/index.md index cc8273d1925..65682b2b897 100644 --- a/public/content/translations/id/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/translations/id/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -725,7 +725,7 @@ These two functions are wrappers around `_initiateERC20Deposit`, the function th ```solidity /** * @dev Performs the logic for deposits by informing the L2 Deposited Token - * contract of the deposit and calling a handler to lock the L1 funds. (e.g. transferFrom) + * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom) * * @param _l1Token Address of the L1 ERC20 we are depositing * @param _l2Token Address of the L1 respective L2 ERC20 diff --git a/public/content/translations/it/developers/docs/storage/index.md b/public/content/translations/it/developers/docs/storage/index.md index 4ac5cd53e1b..ef3bd169125 100644 --- a/public/content/translations/it/developers/docs/storage/index.md +++ b/public/content/translations/it/developers/docs/storage/index.md @@ -25,7 +25,7 @@ Affinché un dato persista nel tempo, occorre usare un meccanismo di persistenza Questo meccanismo prende il nome di persistenza **basata sulla blockchain**. -Il problema della persistenza basata sulla blockchain è che la chain potrebbe diventare troppo grande per mantenere e memorizzare tutti i dati in modo fattibile (e.g. [molte fonti](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) stimano che, per fare ciò, internet richieda una capacità di archiviazione di oltre 40 Zetabyte). +Il problema della persistenza basata sulla blockchain è che la chain potrebbe diventare troppo grande per mantenere e memorizzare tutti i dati in modo fattibile (e.g., [molte fonti](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) stimano che, per fare ciò, internet richieda una capacità di archiviazione di oltre 40 Zetabyte). La blockchain deve anche avere qualche tipo di struttura d'incentivazione. Per la persistenza basata sulla blockchain, esiste un pagamento effettuato al validatore. Quando i dati sono aggiunti alla catena, i validatori sono pagati per aggiungervi i dati. diff --git a/public/content/translations/it/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/it/developers/tutorials/erc20-annotated-code/index.md index 4c2720016b4..cc0c1499d79 100644 --- a/public/content/translations/it/developers/tutorials/erc20-annotated-code/index.md +++ b/public/content/translations/it/developers/tutorials/erc20-annotated-code/index.md @@ -594,7 +594,7 @@ Queste sono le quattro funzioni che effettuano il lavoro effettivo: `_transfer`, * @dev Moves tokens `amount` from `sender` to `recipient`. * * This is internal function is equivalent to {transfer}, and can be used to - * e.g. implement automatic token fees, slashing mechanisms, etc. + * e.g., implement automatic token fees, slashing mechanisms, etc. * * Emits a {Transfer} event. * @@ -715,7 +715,7 @@ Questa è la funzione che specifica concretamente i margini di tolleranza. Nota * @dev Sets `amount` as the allowance of `spender` over the caller's tokens. * * This internal function is equivalent to `approve`, and can be used to - * e.g. set automatic allowances for certain subsystems, etc. + * e.g., set automatic allowances for certain subsystems, etc. * * Emits an {Approval} event. * From b558d1b003e14be6c5a88554592f17186bfc5b4b Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:16:49 -0500 Subject: [PATCH 168/212] hard stops on security/index --- public/content/security/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/security/index.md b/public/content/security/index.md index 21f3a51e237..446af365b67 100644 --- a/public/content/security/index.md +++ b/public/content/security/index.md @@ -105,7 +105,7 @@ A high-profile version of this occurred in July 2020, when the Twitter accounts The celebrity giveaway is another common form the giveaway scam takes. The scammers will take a recorded video interview or conference talk given a celebrity and livestream it on YouTube - making it appear as though the celebrity was giving a live video interview endorsing a cryptocurrency giveaway. -Vitalik Buterin is used most often in this scam, but many other prominent people involved in crypto are also used (e.g. Elon Musk or Charles Hoskinson). Including a well-known person gives the scammers livestream a sense of legitimacy (this looks sketchy, but Vitalik is involved, so it must be ok!). +Vitalik Buterin is used most often in this scam, but many other prominent people involved in crypto are also used (e.g., Elon Musk or Charles Hoskinson). Including a well-known person gives the scammers livestream a sense of legitimacy (this looks sketchy, but Vitalik is involved, so it must be ok!). **Giveaways are always scams. If you send your funds to these accounts, you will lose them forever.** From f23479de2ae8194044039a625cf1c455d45d0721 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:17:11 -0500 Subject: [PATCH 169/212] hard stops statelessness/index --- public/content/roadmap/statelessness/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/roadmap/statelessness/index.md b/public/content/roadmap/statelessness/index.md index 4f3d6b7767a..91d0850030e 100644 --- a/public/content/roadmap/statelessness/index.md +++ b/public/content/roadmap/statelessness/index.md @@ -56,7 +56,7 @@ Statelessness is a bit of a misnomer because it does not mean the concept of "st - nearly instant syncing - ability to validate blocks out-of-order -- nodes able to run with very low hardware requirements (e.g. on phones) +- nodes able to run with very low hardware requirements (e.g., on phones) - nodes can run on top of cheap hard drives because there is no disk reading/writing required - compatible with future upgrades to Ethereum's cryptography From 55b64e4d8b39987f1749ca99bf63fd9a205f0878 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:18:03 -0500 Subject: [PATCH 170/212] hard stops on maxeb/index --- public/content/roadmap/pectra/maxeb/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/roadmap/pectra/maxeb/index.md b/public/content/roadmap/pectra/maxeb/index.md index 512c8d25476..ff4d5e104cd 100644 --- a/public/content/roadmap/pectra/maxeb/index.md +++ b/public/content/roadmap/pectra/maxeb/index.md @@ -12,9 +12,9 @@ lang: en ### Who is affected? {#who-is-affected} -Anyone who runs a validator - this is likely someone who knows the index (e.g. [Validator #12345](https://beaconcha.in/validator/12345)) of a validator that they control. If you use a protocol to run a validator (e.g. Lido CSM or Rocket Pool), you will have to check with them to see if and when they support maxEB. +Anyone who runs a validator - this is likely someone who knows the index (e.g., [Validator #12345](https://beaconcha.in/validator/12345)) of a validator that they control. If you use a protocol to run a validator (e.g., Lido CSM or Rocket Pool), you will have to check with them to see if and when they support maxEB. -If you stake using a liquid staking token (e.g. rETH or stETH), no action is required or recommended. +If you stake using a liquid staking token (e.g., rETH or stETH), no action is required or recommended. ### What is "maxEB"? {#what-is-maxeb} @@ -101,8 +101,8 @@ The target validator must The consolidation request will be signed by the withdrawal address associated with the source validator and have: -1. Address of the source validator (e.g. `0x15F4B914A0cCd14333D850ff311d6DafbFbAa32b`) -2. Public key of the source validator (e.g. `0xa1d1ad0714035353258038e964ae9675dc0252ee22cea896825c01458e1807bfad2f9969338798548d9858a571f7425c`) +1. Address of the source validator (e.g., `0x15F4B914A0cCd14333D850ff311d6DafbFbAa32b`) +2. Public key of the source validator (e.g., `0xa1d1ad0714035353258038e964ae9675dc0252ee22cea896825c01458e1807bfad2f9969338798548d9858a571f7425c`) 3. Public key of that target validator In a conversion, 2 & 3 will be the same. This operation can be done on [the Launchpad](https://launchpad.ethereum.org/). From e35a7e0b270727eef3d308b7cd1840b46805b905 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:18:39 -0500 Subject: [PATCH 171/212] hard stops on pectra/7702/index --- public/content/roadmap/pectra/7702/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/roadmap/pectra/7702/index.md b/public/content/roadmap/pectra/7702/index.md index 0fb2f3fc943..d9ef9d736f3 100644 --- a/public/content/roadmap/pectra/7702/index.md +++ b/public/content/roadmap/pectra/7702/index.md @@ -29,7 +29,7 @@ The private key of the EOA retains full control over the account after the deleg **Account Abstraction**: A delegation contract should align with Ethereum’s broader account abstraction (AA) standards to maximize compatibility. In particular, it should ideally be ERC-4337 compliant or compatible. -**Permissionless and Censorship-Resistant Design**: Ethereum values permissionless participation. A delegation contract MUST NOT hard-code or rely on any single “trusted” relayer or service. This would brick the account if the relayer goes offline. Features like batching (e.g. approve+transferFrom) can be used by the EOA itself without a relayer. For application developers that want to use advanced features enabled by 7702 (Gas Abstraction, Privacy-Preserving Withdrawals) you’ll need a relayer. While there are different relayer architectures, our recommendation is to use [4337 bundlers](https://www.erc4337.io/bundlers) pointing at least [entry point 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) because: +**Permissionless and Censorship-Resistant Design**: Ethereum values permissionless participation. A delegation contract MUST NOT hard-code or rely on any single “trusted” relayer or service. This would brick the account if the relayer goes offline. Features like batching (e.g., approve+transferFrom) can be used by the EOA itself without a relayer. For application developers that want to use advanced features enabled by 7702 (Gas Abstraction, Privacy-Preserving Withdrawals) you’ll need a relayer. While there are different relayer architectures, our recommendation is to use [4337 bundlers](https://www.erc4337.io/bundlers) pointing at least [entry point 0.8](https://github.com/eth-infinitism/account-abstraction/releases/tag/v0.8.0) because: - They provide standardized interfaces for relaying - Include built-in paymaster systems @@ -60,7 +60,7 @@ For more information: **Privacy Preservation**: While onchain privacy is limited, a delegation contract should strive to minimize data exposure and linkability. This can be achieved by supporting features like gas payments in ERC-20 tokens (so users need not maintain a public ETH balance, which improves privacy and UX) and one-time session keys (which reduce reliance on a single long-term key). For example, EIP-7702 enables paying gas in tokens via sponsored transactions, and a good implementation will make it easy to integrate such paymasters without leaking more information than necessary. Additionally, off-chain delegation of certain approvals (using signatures that are verified onchain) means fewer onchain transactions with the user’s primary key, aiding privacy. Accounts that require using a relayer force users to reveal their IP addresses. PublicMempools improves this, when a transaction/UserOp propagates through the mempool you can't tell whether it originated from the IP that sent it, or just relayed through it via the p2p protocol. -**Extensibility and Modular Security**: Account implementations should be extensible so they can evolve with new features and security improvements. Upgradability is inherently possible with EIP-7702 (since an EOA can always delegate to a new contract in the future to upgrade its logic). Beyond upgradability, a good design allows modularity – e.g. plug-in modules for different signature schemes or spending policies – without needing to redeploy entirely. Alchemy’s Account Kit is a prime example, allowing developers to install validation modules (for different signature types like ECDSA, BLS, etc.) and execution modules for custom logic. To achieve greater flexibility and security in EIP-7702-enabled accounts, developers are encouraged to delegate to a proxy contract rather than directly to a specific implementation. This approach allows for seamless upgrades and modularity without requiring additional EIP-7702 authorizations for each change. +**Extensibility and Modular Security**: Account implementations should be extensible so they can evolve with new features and security improvements. Upgradability is inherently possible with EIP-7702 (since an EOA can always delegate to a new contract in the future to upgrade its logic). Beyond upgradability, a good design allows modularity – e.g., plug-in modules for different signature schemes or spending policies – without needing to redeploy entirely. Alchemy’s Account Kit is a prime example, allowing developers to install validation modules (for different signature types like ECDSA, BLS, etc.) and execution modules for custom logic. To achieve greater flexibility and security in EIP-7702-enabled accounts, developers are encouraged to delegate to a proxy contract rather than directly to a specific implementation. This approach allows for seamless upgrades and modularity without requiring additional EIP-7702 authorizations for each change. Benefits of the Proxy Pattern: From 8f729adc3f48b1b7e3dfdaa7ed1d120567ac86ba Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:19:03 -0500 Subject: [PATCH 172/212] hard stops on pectra/index --- public/content/roadmap/pectra/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/roadmap/pectra/index.md b/public/content/roadmap/pectra/index.md index 4276c890b16..03543d99ffe 100644 --- a/public/content/roadmap/pectra/index.md +++ b/public/content/roadmap/pectra/index.md @@ -62,11 +62,11 @@ Validator deposits are currently processed by [eth1data poll](https://eth2book.i ### Precompile for BLS12-381 {#2537} -Precompiles are a special set of smart contracts built directly into the Ethereum Virtual Machine ([EVM](/developers/docs/evm/)). Unlike regular contracts, precompiles are not deployed by users but are part of the client implementation itself, written in its native language (e.g. Go, Java, etc, not Solidity). Precompiles serve for widely used and standardized functions like cryptographic operations. Smart contract developers can call precompiles as a regular contract but with more security and efficiency. +Precompiles are a special set of smart contracts built directly into the Ethereum Virtual Machine ([EVM](/developers/docs/evm/)). Unlike regular contracts, precompiles are not deployed by users but are part of the client implementation itself, written in its native language (e.g., Go, Java, etc, not Solidity). Precompiles serve for widely used and standardized functions like cryptographic operations. Smart contract developers can call precompiles as a regular contract but with more security and efficiency. [EIP-2537](https://eips.ethereum.org/EIPS/eip-2537) adds new precompiles for curve operations over [BLS12-381](https://hackmd.io/@benjaminion/bls12-381). This elliptic curve became widely used in cryptocurrency ecosystems thanks to its practical properties. More specifically, it's been adopted by Ethereum's consensus layer, where it's used by validators. -The new precompile adds the ability for every developer to easily, efficiently, and securely perform cryptographic operations using this curve, for example, verifying signatures. Onchain applications that depend on this curve can become more gas efficient and secure relying on a precompile instead of some custom contract. This mainly applies to applications that want to reason about validators inside the EVM, e.g. staking pools, restaking, light clients, bridges but also zero-knowledge. +The new precompile adds the ability for every developer to easily, efficiently, and securely perform cryptographic operations using this curve, for example, verifying signatures. Onchain applications that depend on this curve can become more gas efficient and secure relying on a precompile instead of some custom contract. This mainly applies to applications that want to reason about validators inside the EVM, e.g., staking pools, restaking, light clients, bridges but also zero-knowledge. ### Serve historical block hashes from state {#2935} From 7333062cbdaaa24d148b07f21f0abb3cbedbcf1b Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:19:20 -0500 Subject: [PATCH 173/212] hard stops on pbs/index --- public/content/roadmap/pbs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/roadmap/pbs/index.md b/public/content/roadmap/pbs/index.md index d9f79124074..b4ff9925917 100644 --- a/public/content/roadmap/pbs/index.md +++ b/public/content/roadmap/pbs/index.md @@ -26,7 +26,7 @@ Powerful organizations can pressure validators to censor transactions to or from ## PBS and MEV {#pbs-and-mev} -**Maximum extractable value (MEV)** refers to validators maximizing their profitability by favorably ordering transactions. Common examples include arbitraging swaps on decentralized exchanges (e.g. frontrunning a large sale or purchase) or identifying opportunities to liquidate DeFi positions. Maximizing MEV requires sophisticated technical know-how and custom software appended to normal validators, making it much more likely that institutional operators outperform individuals and hobbyist validators at MEV extraction. This means staking returns are likely to be higher with centralized operators, creating a centralizing force that disincentivizes home staking. +**Maximum extractable value (MEV)** refers to validators maximizing their profitability by favorably ordering transactions. Common examples include arbitraging swaps on decentralized exchanges (e.g., frontrunning a large sale or purchase) or identifying opportunities to liquidate DeFi positions. Maximizing MEV requires sophisticated technical know-how and custom software appended to normal validators, making it much more likely that institutional operators outperform individuals and hobbyist validators at MEV extraction. This means staking returns are likely to be higher with centralized operators, creating a centralizing force that disincentivizes home staking. PBS solves this problem by reconfiguring the economics of MEV. Instead of the block proposer doing their own MEV searching, they simply pick a block from many offered to them by block builders. The block builders might have done sophisticated MEV extraction, but the reward for it goes to the block proposer. This means that even if a small pool of specialized block builders dominate MEV extraction, the reward for it could go to any validator on the network, including individual home stakers. From c983b715c924c0b7fd9ff5c3260532f1da5b6a89 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:20:02 -0500 Subject: [PATCH 174/212] hard stops on refi/index --- public/content/refi/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/refi/index.md b/public/content/refi/index.md index 7979bd675fd..24dbcf1ddef 100755 --- a/public/content/refi/index.md +++ b/public/content/refi/index.md @@ -22,7 +22,7 @@ One of the foundations of ReFi is the concept of regenerative economics pioneere ![Eight interconnected principles](refi-regenerative-economy-diagram.png) -ReFi projects realize these principles using [smart contracts](/glossary/#smart-contract) and [decentralized finance (DeFi)](/glossary/#defi) applications to incentivize regenerative behaviors, e.g. restoring degraded ecosystems, and facilitate large-scale collaboration on global issues such as climate change and biodiversity loss. +ReFi projects realize these principles using [smart contracts](/glossary/#smart-contract) and [decentralized finance (DeFi)](/glossary/#defi) applications to incentivize regenerative behaviors, e.g., restoring degraded ecosystems, and facilitate large-scale collaboration on global issues such as climate change and biodiversity loss. ReFi also overlaps with the [decentralized science (DeSci)](/desci/) movement, which uses Ethereum as a platform to finance, create, review, credit, store, and disseminate scientific knowledge. DeSci tools could become useful for developing verifiable standards and practices for implementing and monitoring regenerative activities like planting trees, removing plastic from the ocean, or restoring a degraded ecosystem. @@ -32,7 +32,7 @@ ReFi also overlaps with the [decentralized science (DeSci)](/desci/) movement, w The **[voluntary carbon market (VCM)](https://climatefocus.com/so-what-voluntary-carbon-market-exactly/)** is a mechanism for funding projects that make a verified positive impact on carbon emissions, either reducing ongoing emissions, or removing greenhouse gases already emitted from the atmosphere. These projects receive an asset called "carbon credits" after they are verified, which they can sell to individuals and organizations who want to support climate action. -In addition to the VCM, there are also several government-mandated carbon markets (‘compliance markets’) that aim to establish a carbon price via laws or regulations within a particular jurisdiction (e.g. country or region), controlling the supply of permits to be distributed. Compliance markets incentivize polluters within their jurisdiction to reduce emissions, but they are not capable of removing greenhouse gases which have already been emitted. +In addition to the VCM, there are also several government-mandated carbon markets (‘compliance markets’) that aim to establish a carbon price via laws or regulations within a particular jurisdiction (e.g., country or region), controlling the supply of permits to be distributed. Compliance markets incentivize polluters within their jurisdiction to reduce emissions, but they are not capable of removing greenhouse gases which have already been emitted. Despite its development over recent decades, the VCM continues to suffer from a variety of issues: From 0230eda46b15c9e612a1bd6de495314bc930c284 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:20:34 -0500 Subject: [PATCH 175/212] hard stops on privacy-policy/index --- public/content/privacy-policy/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/privacy-policy/index.md b/public/content/privacy-policy/index.md index f1bd74545e4..9a5c2bf441d 100644 --- a/public/content/privacy-policy/index.md +++ b/public/content/privacy-policy/index.md @@ -53,7 +53,7 @@ Many Internet sites and servers use cookies. Many cookies contain a so-called co Through the use of cookies, the Foundation may provide the users of the Websites with more user-friendly services that would not be possible without the cookie setting. -Cookies may allow us, as previously mentioned, to recognize our Website users. The purpose of this recognition is to make it easier for users to utilize our Websites. The Website user that uses cookies, e.g. does not have to enter access data each time the Website is accessed, because this is taken over by the Website, and the cookie is thus stored on the user's computer system. +Cookies may allow us, as previously mentioned, to recognize our Website users. The purpose of this recognition is to make it easier for users to utilize our Websites. The Website user that uses cookies, e.g., does not have to enter access data each time the Website is accessed, because this is taken over by the Website, and the cookie is thus stored on the user's computer system. You may, at any time, prevent the setting of cookies through our Websites by means of a corresponding setting of the Internet browser used, and may thus permanently deny the setting of cookies. Furthermore, previously set cookies may be deleted at any time via an Internet browser or other software programs. This is possible in all popular Internet browsers. If the data subject deactivates the setting of cookies in the Internet browser used, it may not be possible to use all the functions of our Websites. @@ -105,7 +105,7 @@ We may use plug-ins from social networks such as Blog, GitHub, YouTube, Reddit, To register for any event organized by the Foundation through our Websites, we may require the following registration data: First and last name, language, company affiliation, company title, credit card information, e-mail address. -We may use this information as well as other information you voluntarily provide (e.g. preferences, comments) only in order to execute the reservation agreement, unless otherwise stated in this Privacy Policy or you have not specifically consented thereto. +We may use this information as well as other information you voluntarily provide (e.g., preferences, comments) only in order to execute the reservation agreement, unless otherwise stated in this Privacy Policy or you have not specifically consented thereto. We may process the data by name in order to record your reservation as you have requested, to contact you in case of a question or problem and to ensure correct payment. @@ -132,7 +132,7 @@ They are obliged to protect data privacy to the same extent as we ourselves. If We use appropriate technical and organizational security measures to protect your stored personal data against manipulation, partial or complete loss, and unauthorized access by third parties. Our security measures are continuously being improved in line with technical developments. -Please note that any data transmission on the Internet (e.g. communication by e-mail) is generally not secure and we accept no liability for data transmitted to us via the Internet. Unfortunately, absolute protection is not technically possible. +Please note that any data transmission on the Internet (e.g., communication by e-mail) is generally not secure and we accept no liability for data transmitted to us via the Internet. Unfortunately, absolute protection is not technically possible. This information does not apply to the Websites of third parties and the corresponding links given on our Websites. The Foundation assumes no responsibility and liability for these. From ac1224305aa7146d163f6bb7f16f00c1f1041981 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:20:59 -0500 Subject: [PATCH 176/212] hard stops on prediction-markets/index --- public/content/prediction-markets/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/prediction-markets/index.md b/public/content/prediction-markets/index.md index bfd97221f07..e2d48f070ae 100644 --- a/public/content/prediction-markets/index.md +++ b/public/content/prediction-markets/index.md @@ -38,7 +38,7 @@ Unlike traditional forecasting, blockchain-based prediction markets are: Even as an observer of the market, you can assess valuable data that would be otherwise unavailable. Think of it like this: -1. Predictions are tied to a specific event (e.g. Will Beam Chain deploy by 2030?). +1. Predictions are tied to a specific event (e.g., Will Beam Chain deploy by 2030?). 2. Market participants buy and sell shares based on their confidence in any outcome. 3. Prices adjust as more participants stake their beliefs, reflecting real-time insights. 4. Anyone betting correctly earns proportionately to the amount staked.  From 5dced96f84655107acf4dbc438a62e0ad57f06b9 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:21:19 -0500 Subject: [PATCH 177/212] hard stops on nft/index --- public/content/nft/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/nft/index.md b/public/content/nft/index.md index 9d473b44d73..42c953e7ca9 100644 --- a/public/content/nft/index.md +++ b/public/content/nft/index.md @@ -53,7 +53,7 @@ NFTs are used for many things, including: - decentralized internet domain names - collateral in [decentralized finance](/glossary/#defi) -Maybe you are an artist that wants to share their work using NFTs, without losing control and sacrificing your profits to intermediaries. You can create a new contract and specify the number of NFTs, their properties and a link to some specific artwork. As the artist, **you can program into the smart contract the royalties** you should be paid (e.g. transfer 5% of the sale price to the contract owner each time an NFT is transferred). You can also always prove that you created the NFTs because you own the [wallet](/glossary/#wallet) that deployed the contract. Your buyers can easily prove that they own an **authentic NFT** from your collection because their wallet [address](/glossary/#address) is associated with a token in your smart contract. They can use it across the Ethereum ecosystem, confident in its authenticity. +Maybe you are an artist that wants to share their work using NFTs, without losing control and sacrificing your profits to intermediaries. You can create a new contract and specify the number of NFTs, their properties and a link to some specific artwork. As the artist, **you can program into the smart contract the royalties** you should be paid (e.g., transfer 5% of the sale price to the contract owner each time an NFT is transferred). You can also always prove that you created the NFTs because you own the [wallet](/glossary/#wallet) that deployed the contract. Your buyers can easily prove that they own an **authentic NFT** from your collection because their wallet [address](/glossary/#address) is associated with a token in your smart contract. They can use it across the Ethereum ecosystem, confident in its authenticity.
Explore, buy or create your own NFT art/collectibles...
From 0fcc52e691eaaa85aceb7915282c67110173b360 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:22:01 -0500 Subject: [PATCH 178/212] hard stops on governance/index --- public/content/governance/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/governance/index.md b/public/content/governance/index.md index e75edc18972..b3219de45f1 100644 --- a/public/content/governance/index.md +++ b/public/content/governance/index.md @@ -44,13 +44,13 @@ There are various stakeholders in the [Ethereum community](/community/), each pl - **Ether holders**: these people hold an arbitrary amount of ETH. [More on ETH](/eth/). - **Application Users**: these people interact with applications on the Ethereum blockchain. -- **Application/Tooling Developers**: these people write applications that run on the Ethereum blockchain (e.g. DeFi, NFTs, etc.) or build tooling to interact with Ethereum (e.g. wallets, test suites, etc.). [More on dapps](/apps/). +- **Application/Tooling Developers**: these people write applications that run on the Ethereum blockchain (e.g., DeFi, NFTs, etc.) or build tooling to interact with Ethereum (e.g., wallets, test suites, etc.). [More on dapps](/apps/). - **Node Operators**: these people run nodes that propagate blocks and transactions, rejecting any invalid transaction or block that they come across. [More on nodes](/developers/docs/nodes-and-clients/). - **EIP Authors**: these people propose changes to the Ethereum protocol, in the form of Ethereum Improvement Proposals (EIPs). [More on EIPs](/eips/). - **Validators**: these people run nodes that can add new blocks to the Ethereum blockchain. -- **Protocol Developers** (a.k.a. "Core Developers" ): these people maintain the various Ethereum implementations (e.g. go-ethereum, Nethermind, Besu, Erigon, Reth at the execution layer or Prysm, Lighthouse, Nimbus, Teku, Lodestar, Grandine at the consensus layer). [More on Ethereum clients](/developers/docs/nodes-and-clients/). +- **Protocol Developers** (a.k.a. "Core Developers" ): these people maintain the various Ethereum implementations (e.g., go-ethereum, Nethermind, Besu, Erigon, Reth at the execution layer or Prysm, Lighthouse, Nimbus, Teku, Lodestar, Grandine at the consensus layer). [More on Ethereum clients](/developers/docs/nodes-and-clients/). -_Note: any individual can be part of multiple of these groups (e.g. a protocol developer could champion an EIP, and run a beacon chain validator, and use DeFi applications). For conceptual clarity, it is easiest to distinguish between them, though._ +_Note: any individual can be part of multiple of these groups (e.g., a protocol developer could champion an EIP, and run a beacon chain validator, and use DeFi applications). For conceptual clarity, it is easiest to distinguish between them, though._ @@ -102,7 +102,7 @@ While some EIPs are straightforward technical improvements with minimal nuance, There is no clear playbook on how to handle contentious proposals. This is a result of Ethereum's decentralized design whereby no single stakeholder group can coerce the other through brute force: protocol developers can choose not to implement code changes; node operators can choose not to run the latest Ethereum client; application teams and users can choose not to transact on the chain. Since Protocol Developers have no way to force people to adopt network upgrades, they will generally avoid implementing EIPs where the contentiousness outweighs the benefits to the broader community. -EIP Champions are expected to solicit feedback from all relevant stakeholders. If you find yourself the champion of a contentious EIP, you should try and address objections to build consensus around your EIP. Given the size and diversity of the Ethereum community, there isn't a single metric (e.g. a coin vote) that can be used to gauge community consensus, and EIP Champions are expected to adapt to the circumstances of their proposal. +EIP Champions are expected to solicit feedback from all relevant stakeholders. If you find yourself the champion of a contentious EIP, you should try and address objections to build consensus around your EIP. Given the size and diversity of the Ethereum community, there isn't a single metric (e.g., a coin vote) that can be used to gauge community consensus, and EIP Champions are expected to adapt to the circumstances of their proposal. Beyond the security of the Ethereum network, significant weight has historically been placed by Protocol Developers on what Application/Tooling Developers and Application Users value, given that their using and developing on Ethereum is what makes the ecosystem attractive for other stakeholders. Additionally, EIPs need to be implemented across all client implementations, which are managed by distinct teams. Part of this process usually means convincing multiple teams of Protocol Developers that a particular change is valuable and that it helps end-users or solves a security issue. From d2df916f1966c5f5764fdf16ea8ac9828499d91c Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:22:42 -0500 Subject: [PATCH 179/212] hard stops on energy-consumption/index --- public/content/energy-consumption/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/energy-consumption/index.md b/public/content/energy-consumption/index.md index c9fca235ebf..02e75455f01 100644 --- a/public/content/energy-consumption/index.md +++ b/public/content/energy-consumption/index.md @@ -59,7 +59,7 @@ CCRI estimates that The Merge reduced Ethereum's annualized electricity consumpt While Ethereum's energy consumption is very low, there is also a substantial, growing, and highly active [**regenerative finance (ReFi)**](/refi/) community building on Ethereum. ReFi applications use DeFi components to build financial applications that have positive externalities benefiting the environment. ReFi is part of a wider ["solarpunk"](https://en.wikipedia.org/wiki/Solarpunk) movement that is closely aligned with Ethereum and aims to couple technological advancement and environmental stewardship. The decentralized, permissionless, and composable nature of Ethereum makes it the ideal base layer for the ReFi and solarpunk communities. -Web3 native public goods funding platforms such as [Gitcoin](https://gitcoin.co) run climate rounds to stimulate environmentally conscious building on Ethereum's application layer. Through the development of these initiatives (and others, e.g. [DeSci](/desci/)), Ethereum is becoming an environmentally and socially net-positive technology. +Web3 native public goods funding platforms such as [Gitcoin](https://gitcoin.co) run climate rounds to stimulate environmentally conscious building on Ethereum's application layer. Through the development of these initiatives (and others, e.g., [DeSci](/desci/)), Ethereum is becoming an environmentally and socially net-positive technology. If you think this page can be made more accurate, please raise an issue or PR. The stats on this page are estimates based on publicly available data - they do not represent an official statement or promise from the ethereum.org team, or the Ethereum Foundation. From aaf0da1cbb03e229c7690c036aa57843ee2775ac Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:23:03 -0500 Subject: [PATCH 180/212] hard stops on token-integration-checklist/index --- .../developers/tutorials/token-integration-checklist/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/tutorials/token-integration-checklist/index.md b/public/content/developers/tutorials/token-integration-checklist/index.md index 58821da9f09..92088341817 100644 --- a/public/content/developers/tutorials/token-integration-checklist/index.md +++ b/public/content/developers/tutorials/token-integration-checklist/index.md @@ -59,7 +59,7 @@ Finally, there are certain characteristics that are difficult to identify automa - **The contract avoids unneeded complexity.** The token should be a simple contract; a token with complex code requires a higher standard of review. Use Slither’s [human-summary printer](https://github.com/crytic/slither/wiki/Printer-documentation#human-summary) to identify complex code. - **The contract uses SafeMath.** Contracts that do not use SafeMath require a higher standard of review. Inspect the contract by hand for SafeMath usage. - **The contract has only a few non–token-related functions.** Non–token-related functions increase the likelihood of an issue in the contract. Use Slither’s [contract-summary printer](https://github.com/crytic/slither/wiki/Printer-documentation#contract-summary) to broadly review the code used in the contract. -- **The token only has one address.** Tokens with multiple entry points for balance updates can break internal bookkeeping based on the address (e.g. `balances[token_address][msg.sender]` might not reflect the actual balance). +- **The token only has one address.** Tokens with multiple entry points for balance updates can break internal bookkeeping based on the address (e.g., `balances[token_address][msg.sender]` might not reflect the actual balance). ## Owner privileges {#owner-privileges} From 85ae5d855f38adc54c7d90c4ce813e115f172f11 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:23:30 -0500 Subject: [PATCH 181/212] hard stops on optimism-std-bridge-annotated-code/index --- .../tutorials/optimism-std-bridge-annotated-code/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/tutorials/optimism-std-bridge-annotated-code/index.md b/public/content/developers/tutorials/optimism-std-bridge-annotated-code/index.md index f0e7c7118cd..4d50e93a1f8 100644 --- a/public/content/developers/tutorials/optimism-std-bridge-annotated-code/index.md +++ b/public/content/developers/tutorials/optimism-std-bridge-annotated-code/index.md @@ -769,7 +769,7 @@ These two functions are wrappers around `_initiateERC20Deposit`, the function th ```solidity /** * @dev Performs the logic for deposits by informing the L2 Deposited Token - * contract of the deposit and calling a handler to lock the L1 funds. (e.g. transferFrom) + * contract of the deposit and calling a handler to lock the L1 funds. (e.g., transferFrom) * * @param _l1Token Address of the L1 ERC20 we are depositing * @param _l2Token Address of the L1 respective L2 ERC20 From 71ed7137f93fd151e4e640f029d7362afaabafeb Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:23:59 -0500 Subject: [PATCH 182/212] hard stops on how-to-use-tellor-as-your-oracle/index --- .../tutorials/how-to-use-tellor-as-your-oracle/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md b/public/content/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md index d425324a6e3..49b87ac4389 100644 --- a/public/content/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md +++ b/public/content/developers/tutorials/how-to-use-tellor-as-your-oracle/index.md @@ -26,7 +26,7 @@ Tellor is a live and open-sourced oracle ready for implementation. This beginner ## Overview {#overview} -Tellor is an oracle system where parties can request the value of an offchain data point (e.g. BTC/USD) and reporters compete to add this value to an onchain data-bank, accessible by all Ethereum smart contracts. The inputs to this data-bank are secured by a network of staked reporters. Tellor utilizes crypto-economic incentive mechanisms, rewarding honest data submissions by reporters and punishing bad actors through the issuance of Tellor’s token, Tributes (TRB), and a dispute mechanism. +Tellor is an oracle system where parties can request the value of an offchain data point (e.g., BTC/USD) and reporters compete to add this value to an onchain data-bank, accessible by all Ethereum smart contracts. The inputs to this data-bank are secured by a network of staked reporters. Tellor utilizes crypto-economic incentive mechanisms, rewarding honest data submissions by reporters and punishing bad actors through the issuance of Tellor’s token, Tributes (TRB), and a dispute mechanism. In this tutorial we'll go over: From 3a5276c9ae1ac1dbe392a43939f676bf32af2cb8 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:24:41 -0500 Subject: [PATCH 183/212] hard stops on erc20-annotated-code/index --- .../developers/tutorials/erc20-annotated-code/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/tutorials/erc20-annotated-code/index.md b/public/content/developers/tutorials/erc20-annotated-code/index.md index af7750a4c33..256a5494063 100644 --- a/public/content/developers/tutorials/erc20-annotated-code/index.md +++ b/public/content/developers/tutorials/erc20-annotated-code/index.md @@ -688,7 +688,7 @@ These are the four functions that do the actual work: `_transfer`, `_mint`, `_bu * @dev Moves tokens `amount` from `sender` to `recipient`. * * This is internal function is equivalent to {transfer}, and can be used to - * e.g. implement automatic token fees, slashing mechanisms, etc. + * e.g., implement automatic token fees, slashing mechanisms, etc. * * Emits a {Transfer} event. * @@ -831,7 +831,7 @@ created. * @dev Sets `amount` as the allowance of `spender` over the `owner` s tokens. * * This internal function is equivalent to `approve`, and can be used to - * e.g. set automatic allowances for certain subsystems, etc. + * e.g., set automatic allowances for certain subsystems, etc. * * Emits an {Approval} event. * From 8b9e7227b4c6db68adec5caa0cb978716333051a Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:26:14 -0500 Subject: [PATCH 184/212] hard stops on calling-a-smart-contract-from-javascript/index --- .../tutorials/calling-a-smart-contract-from-javascript/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/tutorials/calling-a-smart-contract-from-javascript/index.md b/public/content/developers/tutorials/calling-a-smart-contract-from-javascript/index.md index 3188e553c49..8970b41c25d 100644 --- a/public/content/developers/tutorials/calling-a-smart-contract-from-javascript/index.md +++ b/public/content/developers/tutorials/calling-a-smart-contract-from-javascript/index.md @@ -11,7 +11,7 @@ sourceUrl: https://ethereumdev.io/calling-a-smart-contract-from-javascript/ address: "0x19dE91Af973F404EDF5B4c093983a7c6E3EC8ccE" --- -In this tutorial we’ll see how to call a [smart contract](/developers/docs/smart-contracts/) function from JavaScript. First is reading the state of a smart contract (e.g. the balance of an ERC20 holder), then we’ll modify the state of the blockchain by making a token transfer. You should already be familiar with [setting up a JS environment to interact with the blockchain](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/). +In this tutorial we’ll see how to call a [smart contract](/developers/docs/smart-contracts/) function from JavaScript. First is reading the state of a smart contract (e.g., the balance of an ERC20 holder), then we’ll modify the state of the blockchain by making a token transfer. You should already be familiar with [setting up a JS environment to interact with the blockchain](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/). For this example we’ll play with the DAI token, for testing purpose we’ll fork the blockchain using ganache-cli and unlock an address that already has a lot of DAI: From 645a3361f32c8eee52372357b635a55a7af4d0e2 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:26:46 -0500 Subject: [PATCH 185/212] hard stops on storage/index --- public/content/developers/docs/storage/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/storage/index.md b/public/content/developers/docs/storage/index.md index ded3aaebe68..bdcaf01f798 100644 --- a/public/content/developers/docs/storage/index.md +++ b/public/content/developers/docs/storage/index.md @@ -25,7 +25,7 @@ For a piece of data to persist forever, we need to use a persistence mechanism. This is known as **blockchain-based** persistence. -The issue with blockchain-based persistence is that the chain could get far too big to upkeep and store all the data feasibly (e.g. [many sources](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) estimate the Internet to require over 40 Zetabytes of storage capacity). +The issue with blockchain-based persistence is that the chain could get far too big to upkeep and store all the data feasibly (e.g., [many sources](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) estimate the Internet to require over 40 Zetabytes of storage capacity). The blockchain must also have some type of incentive structure. For blockchain-based persistence, there is a payment made to the validator. When the data is added to the chain, the validators are paid to add the data on. From edc80ed3ddcc1018d6f72c300fe31b499ab19a11 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:27:06 -0500 Subject: [PATCH 186/212] hard stops erc-4626/index --- .../content/developers/docs/standards/tokens/erc-4626/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/standards/tokens/erc-4626/index.md b/public/content/developers/docs/standards/tokens/erc-4626/index.md index 88d4a9b62a8..ebb85960190 100644 --- a/public/content/developers/docs/standards/tokens/erc-4626/index.md +++ b/public/content/developers/docs/standards/tokens/erc-4626/index.md @@ -18,7 +18,7 @@ The ERC-4626 token is described fully in [EIP-4626](https://eips.ethereum.org/EI **Asynchronous vault extension (ERC-7540)** -ERC-4626 is optimized for atomic deposits and redemptions up to a limit. If the limit is reached, no new deposits or redemptions can be submitted. This limitation does not work well for any smart contract system with asynchronous actions or delays as a prerequisite for interfacing with the Vault (e.g. real-world asset protocols, undercollateralized lending protocols, cross-chain lending protocols, liquid staking tokens, or insurance safety modules). +ERC-4626 is optimized for atomic deposits and redemptions up to a limit. If the limit is reached, no new deposits or redemptions can be submitted. This limitation does not work well for any smart contract system with asynchronous actions or delays as a prerequisite for interfacing with the Vault (e.g., real-world asset protocols, undercollateralized lending protocols, cross-chain lending protocols, liquid staking tokens, or insurance safety modules). ERC-7540 expands the utility of ERC-4626 Vaults for asynchronous use cases. The existing Vault interface (`deposit`/`withdraw`/`mint`/`redeem`) is fully utilized to claim asynchronous Requests. From 88107a3a7c8982a2c15ee4c03878e525785691b7 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:27:33 -0500 Subject: [PATCH 187/212] hard stops on erc-20/index --- .../content/developers/docs/standards/tokens/erc-20/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/docs/standards/tokens/erc-20/index.md b/public/content/developers/docs/standards/tokens/erc-20/index.md index 47e4560ab50..4a725f40d44 100644 --- a/public/content/developers/docs/standards/tokens/erc-20/index.md +++ b/public/content/developers/docs/standards/tokens/erc-20/index.md @@ -168,8 +168,8 @@ When ERC-20 tokens are sent to a smart contract that is not designed to handle E While it is not possible to prevent this issue with ERC-20 completely there are methods that would allow to significantly reduce the possibility of a tokens loss for the end user: -- The most common problem is when a user sends tokens to the token contract address itself (e.g. USDT deposited to the address of USDT token contract). It is recommended to restrict `transfer(..)` function to revert such transfer attempts. Consider adding `require(_to != address(this));` check within the implementation of the `transfer(..)` function. -- The `transfer(..)` function in general is not designed for depositing tokens to contracts. `approve(..) & transferFrom(..)` pattern is used to deposit ERC-20 tokens to contracts instead. It is possible to restrict the transfer function to disallow depositing tokens to any contracts with it, however it may break compatibility with contracts that assume tokens can be deposited to contracts with the `trasnfer(..)` function (e.g. Uniswap liqudity pools). +- The most common problem is when a user sends tokens to the token contract address itself (e.g., USDT deposited to the address of USDT token contract). It is recommended to restrict `transfer(..)` function to revert such transfer attempts. Consider adding `require(_to != address(this));` check within the implementation of the `transfer(..)` function. +- The `transfer(..)` function in general is not designed for depositing tokens to contracts. `approve(..) & transferFrom(..)` pattern is used to deposit ERC-20 tokens to contracts instead. It is possible to restrict the transfer function to disallow depositing tokens to any contracts with it, however it may break compatibility with contracts that assume tokens can be deposited to contracts with the `trasnfer(..)` function (e.g., Uniswap liqudity pools). - Always assume that ERC-20 tokens can end up in your contract even if your contract is not supposed to ever receive any. There is no way to prevent or reject accidental deposits on the recipients end. It is recommended to implement a function that would allow to extract accidentally deposited ERC-20 tokens. - Consider using alternative token standards. From 3c1e8075daedadb930c063d6d3a0b84c58d598a7 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:27:54 -0500 Subject: [PATCH 188/212] hard stops on erc-1155/index --- .../content/developers/docs/standards/tokens/erc-1155/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/standards/tokens/erc-1155/index.md b/public/content/developers/docs/standards/tokens/erc-1155/index.md index dfa8ab4c0ed..229637c3a6d 100644 --- a/public/content/developers/docs/standards/tokens/erc-1155/index.md +++ b/public/content/developers/docs/standards/tokens/erc-1155/index.md @@ -6,7 +6,7 @@ lang: en ## Introduction {#introduction} -A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens or other configurations (e.g. semi-fungible tokens). +A standard interface for contracts that manage multiple token types. A single deployed contract may include any combination of fungible tokens, non-fungible tokens or other configurations (e.g., semi-fungible tokens). **What is meant by Multi-Token Standard?** From ba5e5af27f9ff32c6966f32e132c03413b26d3bd Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:28:19 -0500 Subject: [PATCH 189/212] hard stops on development-networks/index --- public/content/developers/docs/development-networks/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/development-networks/index.md b/public/content/developers/docs/development-networks/index.md index 774bb9852cd..d0c00c299f4 100644 --- a/public/content/developers/docs/development-networks/index.md +++ b/public/content/developers/docs/development-networks/index.md @@ -20,7 +20,7 @@ Development networks are essentially Ethereum clients (implementations of Ethere You _could_ [run a node](/developers/docs/nodes-and-clients/#running-your-own-node) but since development networks are purpose-built for development, they often come packed with convenient features like: -- Deterministically seeding your local blockchain with data (e.g. accounts with ETH balances) +- Deterministically seeding your local blockchain with data (e.g., accounts with ETH balances) - Instantly producing blocks with each transaction it receives, in order and with no delay - Enhanced debugging and logging functionality From ce93b3beda922d8dd911e810eb6c715209df4f2f Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:28:43 -0500 Subject: [PATCH 190/212] hard stops on ethereum-stack/index --- public/content/developers/docs/ethereum-stack/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/ethereum-stack/index.md b/public/content/developers/docs/ethereum-stack/index.md index d5faf5309c6..b83af9a071d 100644 --- a/public/content/developers/docs/ethereum-stack/index.md +++ b/public/content/developers/docs/ethereum-stack/index.md @@ -42,7 +42,7 @@ Many convenience libraries (built and maintained by Ethereum's open source commu If your user-facing application is a web app, you may choose to `npm install` a [JavaScript API](/developers/docs/apis/javascript/) directly in your frontend. Or perhaps you'll choose to implement this functionality server-side, using a [Python](/developers/docs/programming-languages/python/) or [Java](/developers/docs/programming-languages/java/) API. -While these APIs are not a necessary piece of the stack, they abstract away much of the complexity of interacting directly with an Ethereum node. They also provide utility functions (e.g. converting ETH to Gwei) so as a developer you can spend less time dealing with the intricacies of Ethereum clients and more time focused on the functionality specific to your application. +While these APIs are not a necessary piece of the stack, they abstract away much of the complexity of interacting directly with an Ethereum node. They also provide utility functions (e.g., converting ETH to Gwei) so as a developer you can spend less time dealing with the intricacies of Ethereum clients and more time focused on the functionality specific to your application. ## Level 5: End-user applications {#end-user-applications} From 14a3eeaf8511dc0caae546edab2b633a364b1eb8 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 11:29:21 -0500 Subject: [PATCH 191/212] hard stops on mev/index --- public/content/developers/docs/mev/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/developers/docs/mev/index.md b/public/content/developers/docs/mev/index.md index c2771a6d427..acd782e87a7 100644 --- a/public/content/developers/docs/mev/index.md +++ b/public/content/developers/docs/mev/index.md @@ -26,7 +26,7 @@ With that, for some highly competitive MEV opportunities, such as [DEX arbitrage This dynamic has made being good at "gas golfing" — programming transactions so that they use the least amount of gas — a competitive advantage, because it allows searchers to set a higher gas price while keeping their total gas fees constant (since gas fees = gas price \* gas used). -A few well-known gas golf techniques include: using addresses that start with a long string of zeroes (e.g. [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://eth.blockscout.com/address/0x0000000000C521824EaFf97Eac7B73B084ef9306)) since they take less space (and hence gas) to store; and leaving small [ERC-20](/developers/docs/standards/tokens/erc-20/) token balances in contracts, since it costs more gas to initialize a storage slot (the case if the balance is 0) than to update a storage slot. Finding more techniques to reduce gas usage is an active area of research among searchers. +A few well-known gas golf techniques include: using addresses that start with a long string of zeroes (e.g., [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://eth.blockscout.com/address/0x0000000000C521824EaFf97Eac7B73B084ef9306)) since they take less space (and hence gas) to store; and leaving small [ERC-20](/developers/docs/standards/tokens/erc-20/) token balances in contracts, since it costs more gas to initialize a storage slot (the case if the balance is 0) than to update a storage slot. Finding more techniques to reduce gas usage is an active area of research among searchers. ### Generalized frontrunners {#mev-extraction-generalized-frontrunners} @@ -52,9 +52,9 @@ It works like this: if two DEXes are offering a token at two different prices, s Lending protocol liquidations present another well-known MEV opportunity. -Lending protocols like Maker and Aave require users to deposit some collateral (e.g. ETH). This deposited collateral is then used to lend out to other users. +Lending protocols like Maker and Aave require users to deposit some collateral (e.g., ETH). This deposited collateral is then used to lend out to other users. -Users can then borrow assets and tokens from others depending on what they need (e.g. you might borrow MKR if you want to vote in a MakerDAO governance proposal) up to a certain percentage of their deposited collateral. For example, if the borrowing amount is a maximum of 30%, a user who deposits 100 DAI into the protocol can borrow up to 30 DAI worth of another asset. The protocol determines the exact borrowing power percentage. +Users can then borrow assets and tokens from others depending on what they need (e.g., you might borrow MKR if you want to vote in a MakerDAO governance proposal) up to a certain percentage of their deposited collateral. For example, if the borrowing amount is a maximum of 30%, a user who deposits 100 DAI into the protocol can borrow up to 30 DAI worth of another asset. The protocol determines the exact borrowing power percentage. As the value of a borrower's collateral fluctuates, so too does their borrowing power. If, due to market fluctuations, the value of borrowed assets exceeds say, 30% of the value of their collateral (again, the exact percentage is determined by the protocol), the protocol typically allows anyone to liquidate the collateral, instantly paying off the lenders (this is similar to how [margin calls](https://www.investopedia.com/terms/m/margincall.asp) work in traditional finance). If liquidated, the borrower usually has to pay a hefty liquidation fee, some of which goes to the liquidator — which is where the MEV opportunity comes in. From 01ade3c58bf235b6c34f711634924af176feaa37 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:28:03 -0500 Subject: [PATCH 192/212] hard stops on best-practices.md --- docs/best-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/best-practices.md b/docs/best-practices.md index 7542e54eaf8..9a5b2b3533b 100644 --- a/docs/best-practices.md +++ b/docs/best-practices.md @@ -8,7 +8,7 @@ How to prepare your content for translation depends on whether you're working on **- MDX pages (`public/content/page/`)** -Markdown will be translated as whole pages of content, so no specific action is required. Simply create a new folder within `public/content/` with the name of the page, then place an index markdown file (ie. `index.md`) within the new folder. +Markdown will be translated as whole pages of content, so no specific action is required. Simply create a new folder within `public/content/` with the name of the page, then place an index markdown file (i.e., `index.md`) within the new folder. **- React component page** From ae762ea5396a2077a95f65d5c30b4f155e9c4937 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:29:02 -0500 Subject: [PATCH 193/212] hard stops on crowdin-import.ts --- src/scripts/crowdin-import.ts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/scripts/crowdin-import.ts b/src/scripts/crowdin-import.ts index c87790b48d8..5fa9b9eeba8 100644 --- a/src/scripts/crowdin-import.ts +++ b/src/scripts/crowdin-import.ts @@ -42,7 +42,7 @@ const argv = require("minimist")(process.argv.slice(2)) * * 2b. Alternatively, you can manually add buckets to import to the USER_OVERRIDE object below. * 1. Add the number of the corresponding content bucket to the chosen language array below - * ie. `es: [1, 10],` would import the "Homepage" and "Learn" buckets for Spanish + * i.e., `es: [1, 10],` would import the "Homepage" and "Learn" buckets for Spanish * 2. Save file without committing* * * Optionally: To view summary of buckets from CSV, run `pnpm crowdin-import --buckets` or `pnpm crowdin-import -b` @@ -51,7 +51,7 @@ const argv = require("minimist")(process.argv.slice(2)) * 3. Export translated content from Crowdin and import into ./.crowdin folder: * 1. Export latest translated content from Crowdin and unzip * 2. Copy languages folder from Crowdin export to ./.crowdin - * ie. ./.crowdin/{lang-codes} + * i.e., ./.crowdin/{lang-codes} * * 4. Execute script: * 1. Execute script by running `pnpm crowdin-import` From a2ccf03f87fb6f34f4d98f1c505fc1f38cb52371 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:29:27 -0500 Subject: [PATCH 194/212] hard stops on archive-nodes/index --- .../docs/nodes-and-clients/archive-nodes/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/developers/docs/nodes-and-clients/archive-nodes/index.md b/public/content/developers/docs/nodes-and-clients/archive-nodes/index.md index 297835b06d6..a179c79fdba 100644 --- a/public/content/developers/docs/nodes-and-clients/archive-nodes/index.md +++ b/public/content/developers/docs/nodes-and-clients/archive-nodes/index.md @@ -17,13 +17,13 @@ To grasp the importance of an archive node, let's clarify the concept of "state. - Account balances and nonces - Contract code and storage -- Consensus-related data, e.g. Staking Deposit Contract +- Consensus-related data, e.g., Staking Deposit Contract -To interact with the network, verify and produce new blocks, Ethereum clients have to keep up with the most recent changes (the tip of the chain) and therefore the current state. An execution layer client configured as a full node verifies and follows the latest state of the network but only caches the past few states, e.g. the state associated with the last 128 blocks, so it can handle chain reorgs and provide fast access to recent data. The recent state is what all clients need to verify incoming transactions and use the network. +To interact with the network, verify and produce new blocks, Ethereum clients have to keep up with the most recent changes (the tip of the chain) and therefore the current state. An execution layer client configured as a full node verifies and follows the latest state of the network but only caches the past few states, e.g., the state associated with the last 128 blocks, so it can handle chain reorgs and provide fast access to recent data. The recent state is what all clients need to verify incoming transactions and use the network. You can imagine the state as a momentary network snapshot at a given block and the archive as a history replay. -Historical states can be safely pruned because they are not necessary for the network to operate and it would be uselessly redundant for client to keep all out-of-date data. States that existed before some recent block (e.g. 128 blocks before the head) are effectively thrown away. Full nodes only keep historical blockchain data (blocks and transactions) and occasional historical snapshots they can use to regenerate older states on request. They do this by re-executing past transactions in the EVM, which can be computationally demanding when the desired state is far from the nearest snapshot. +Historical states can be safely pruned because they are not necessary for the network to operate and it would be uselessly redundant for client to keep all out-of-date data. States that existed before some recent block (e.g., 128 blocks before the head) are effectively thrown away. Full nodes only keep historical blockchain data (blocks and transactions) and occasional historical snapshots they can use to regenerate older states on request. They do this by re-executing past transactions in the EVM, which can be computationally demanding when the desired state is far from the nearest snapshot. However, this means that accessing a historical state on a full node consumes a lot of computation. The client might need to execute all past transactions and compute one historical state from genesis. Archive nodes solve this by storing not only the most recent states but every historical state created after each block. It basically makes a trade-off with bigger disk space requirement. @@ -63,7 +63,7 @@ Apart from general [recommendations for running a node](/developers/docs/nodes-a Always make sure to verify hardware requirements for a given mode in a client's documentation. The biggest requirement for archive nodes is the disk space. Depending on client, it varies from 3TB to 12TB. Even if HDD might be considered a better solution for large amounts of data, syncing it and constantly updating the head of the chain will require SSD drives. [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) drives are good enough but it should be a reliable quality, at least [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences). Disks can be fitted into a desktop computer or a server with enough slots. Such dedicated devices are ideal for running high uptime node. It's totally possible to run it on a laptop but the portability will come at an additional cost. -All of the data needs to fit in one volume, therefore disks have to be joined, e.g. with [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) or LVM. It might be also worth considering using [ZFS](https://en.wikipedia.org/wiki/ZFS) as it supports "Copy-on-write" which ensures data is correctly written to the disk without any low level errors. +All of the data needs to fit in one volume, therefore disks have to be joined, e.g., with [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) or LVM. It might be also worth considering using [ZFS](https://en.wikipedia.org/wiki/ZFS) as it supports "Copy-on-write" which ensures data is correctly written to the disk without any low level errors. For more stability and security in preventing accidental database corruption, especially in a professional setup, consider using [ECC memory](https://en.wikipedia.org/wiki/ECC_memory) if your system supports it. The size of RAM is generally advised to be the same as for a full node but more RAM can help speed up the synchronization. From f68fa4d9265a51e766f928f041bca178f31ad2b0 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:29:41 -0500 Subject: [PATCH 195/212] hard stops on client-diversity/index --- .../developers/docs/nodes-and-clients/client-diversity/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/developers/docs/nodes-and-clients/client-diversity/index.md index cfa0a3da8d3..75d810f70a6 100644 --- a/public/content/developers/docs/nodes-and-clients/client-diversity/index.md +++ b/public/content/developers/docs/nodes-and-clients/client-diversity/index.md @@ -46,7 +46,7 @@ _Diagram data from [ethernodes.org](https://ethernodes.org) and [clientdiversity The two pie charts above show snapshots of the current client diversity for the execution and consensus layers (at time of writing in January 2022). The execution layer is overwhelmingly dominated by [Geth](https://geth.ethereum.org/), with [Open Ethereum](https://openethereum.github.io/) a distant second, [Erigon](https://github.com/ledgerwatch/erigon) third and [Nethermind](https://nethermind.io/) fourth, with other clients comprising less than 1 % of the network. The most commonly used client on the consensus layer - [Prysm](https://prysmaticlabs.com/#projects) - is not as dominant as Geth but still represents over 60% of the network. [Lighthouse](https://lighthouse.sigmaprime.io/) and [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) make up ~20% and ~14% respectively, and other clients are rarely used. -The execution layer data were obtained from [Ethernodes](https://ethernodes.org) on 23-Jan-2022. Data for consensus clients was obtained from [Michael Sproul](https://github.com/sigp/blockprint). Consensus client data is more difficult to obtain because the consensus layer clients do not always have unambiguous traces that can be used to identify them. The data was generated using a classification algorithm that sometimes confuses some of the minority clients (see [here](https://twitter.com/sproulM_/status/1440512518242197516) for more details). In the diagram above, these ambiguous classifications are treated with an either/or label (e.g. Nimbus/Teku). Nevertheless, it is clear that the majority of the network is running Prysm. The data is a snapshot over a fixed set of blocks (in this case Beacon blocks in slots 2048001 to 2164916) and Prysm's dominance has sometimes been higher, exceeding 68%. Despite only being snapshots, the values in the diagram provide a good general sense of the current state of client diversity. +The execution layer data were obtained from [Ethernodes](https://ethernodes.org) on 23-Jan-2022. Data for consensus clients was obtained from [Michael Sproul](https://github.com/sigp/blockprint). Consensus client data is more difficult to obtain because the consensus layer clients do not always have unambiguous traces that can be used to identify them. The data was generated using a classification algorithm that sometimes confuses some of the minority clients (see [here](https://twitter.com/sproulM_/status/1440512518242197516) for more details). In the diagram above, these ambiguous classifications are treated with an either/or label (e.g., Nimbus/Teku). Nevertheless, it is clear that the majority of the network is running Prysm. The data is a snapshot over a fixed set of blocks (in this case Beacon blocks in slots 2048001 to 2164916) and Prysm's dominance has sometimes been higher, exceeding 68%. Despite only being snapshots, the values in the diagram provide a good general sense of the current state of client diversity. Up to date client diversity data for the consensus layer is now available at [clientdiversity.org](https://clientdiversity.org/). From b5e6ec5792dd859a18d7a85d09f7c09cad6cd4b2 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:29:57 -0500 Subject: [PATCH 196/212] hard stops on nodes-as-a-service/index --- .../docs/nodes-and-clients/nodes-as-a-service/index.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/public/content/developers/docs/nodes-and-clients/nodes-as-a-service/index.md b/public/content/developers/docs/nodes-and-clients/nodes-as-a-service/index.md index 483e225cacb..40c24fdb4b2 100644 --- a/public/content/developers/docs/nodes-and-clients/nodes-as-a-service/index.md +++ b/public/content/developers/docs/nodes-and-clients/nodes-as-a-service/index.md @@ -239,14 +239,14 @@ Here is a list of some of the most popular Ethereum node providers, feel free to - 500+ administrative and service APIs - RESTful interface for Ethereum transaction submission (Apache Kafka backed) - Outbound streams for event delivery (Apache Kafka backed) - - Deep collection of "offchain" and ancillary services (e.g. bilateral encrypted messaging transport) + - Deep collection of "offchain" and ancillary services (e.g., bilateral encrypted messaging transport) - Straightforward network onboarding with governance and role-based access control - Sophisticated user management for both administrators and end users - Highly scalable, resilient, enterprise-grade infrastructure - Cloud HSM private key management - Ethereum Mainnet Tethering - ISO 27k and SOC 2, Type 2 certifications - - Dynamic runtime configuration (e.g. adding cloud integrations, altering node ingresses, etc.) + - Dynamic runtime configuration (e.g., adding cloud integrations, altering node ingresses, etc.) - Support for multi-cloud, multi-region and hybrid deployment orchestrations - Simple hourly SaaS-based pricing - SLAs and 24x7 support From 59a39bd8a3b15f20b08bb1128bb2e5440d19492e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:30:12 -0500 Subject: [PATCH 197/212] hard stops on run-a-node/index --- .../nodes-and-clients/run-a-node/index.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/public/content/developers/docs/nodes-and-clients/run-a-node/index.md b/public/content/developers/docs/nodes-and-clients/run-a-node/index.md index d05d92c4300..9349763af1f 100644 --- a/public/content/developers/docs/nodes-and-clients/run-a-node/index.md +++ b/public/content/developers/docs/nodes-and-clients/run-a-node/index.md @@ -101,7 +101,7 @@ The sync mode and client you choose will affect space requirements, but we've es - Note: Erigon and Reth do not offer snap sync, but Full Pruning is possible (~2TB for Erigon, ~1.2TB for Reth) -For consensus clients, space requirement also depends on client implementation and enabled features (e.g. validator slasher) but generally count with another 200GB needed for beacon data. With a large number of validators, the bandwidth load grows as well. You can find [details on consensus client requirements in this analysis](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc). +For consensus clients, space requirement also depends on client implementation and enabled features (e.g., validator slasher) but generally count with another 200GB needed for beacon data. With a large number of validators, the bandwidth load grows as well. You can find [details on consensus client requirements in this analysis](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc). #### Plug-and-play solutions {#plug-and-play} @@ -177,7 +177,7 @@ It is also worth noting that client diversity is an [issue on the execution laye When downloading software from the internet, it's recommended to verify its integrity. This step is optional but especially with crucial infrastructure piece like the Ethereum client, it's important to be aware of potential attack vectors and avoid them. If you downloaded a pre-built binary, you need to trust it and risk that an attacker could swap the executable for a malicious one. -Developers sign released binaries with their PGP keys so you can cryptographically verify you are running exactly the software they created. You just need to obtain public keys used by developers, which can be found on client release pages or in documentation. After downloading the client release and its signature, you can use a PGP implementation, e.g. [GnuPG](https://gnupg.org/download/index.html) to easily verify them. Check out a tutorial on verifying open-source software using `gpg` on [linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) or [Windows/MacOS](https://freedom.press/training/verifying-open-source-software/). +Developers sign released binaries with their PGP keys so you can cryptographically verify you are running exactly the software they created. You just need to obtain public keys used by developers, which can be found on client release pages or in documentation. After downloading the client release and its signature, you can use a PGP implementation, e.g., [GnuPG](https://gnupg.org/download/index.html) to easily verify them. Check out a tutorial on verifying open-source software using `gpg` on [linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) or [Windows/MacOS](https://freedom.press/training/verifying-open-source-software/). Another form of verification is to make sure that the hash, a unique cryptographic fingerprint, of the software you downloaded matches the one provided by developers. This is even easier than using PGP, and some clients offer only this option. Just run the hash function on the downloaded software and compare it to the one from the release page. For example: @@ -191,9 +191,9 @@ sha256sum teku-22.6.1.tar.gz After installing, downloading, or compiling the client software, you are ready to run it. This only means it has to be executed with the proper configuration. Clients offer rich configuration options, which can enable various features. -Let's start with options that can significantly influence client performance and data usage. [Sync modes](/developers/docs/nodes-and-clients/#sync-modes) represent different methods of downloading and validating blockchain data. Before starting the node, you should decide what network and sync mode to use. The most important things to consider are the disk space, and sync time the client will need. Pay attention to the client's docs to determine which sync mode is the default. If that doesn't suit you, pick another one based on the level of security, available data, and cost. Apart from the synchronization algorithm, you can also set pruning of different kinds of old data. Pruning enables deleting outdated data, e.g. removing state trie nodes that are unreachable from recent blocks. +Let's start with options that can significantly influence client performance and data usage. [Sync modes](/developers/docs/nodes-and-clients/#sync-modes) represent different methods of downloading and validating blockchain data. Before starting the node, you should decide what network and sync mode to use. The most important things to consider are the disk space, and sync time the client will need. Pay attention to the client's docs to determine which sync mode is the default. If that doesn't suit you, pick another one based on the level of security, available data, and cost. Apart from the synchronization algorithm, you can also set pruning of different kinds of old data. Pruning enables deleting outdated data, e.g., removing state trie nodes that are unreachable from recent blocks. -Other basic configuration options are, e.g. choosing a network - Mainnet or testnets, enabling HTTP endpoint for RPC or WebSockets, etc. You can find all features and options in the client's documentation. Various client configurations can be set by executing the client with the corresponding flags directly in the CLI or config file. Each client is a bit different; please always refer to its official documentation or help page for details on config options. +Other basic configuration options are, e.g., choosing a network - Mainnet or testnets, enabling HTTP endpoint for RPC or WebSockets, etc. You can find all features and options in the client's documentation. Various client configurations can be set by executing the client with the corresponding flags directly in the CLI or config file. Each client is a bit different; please always refer to its official documentation or help page for details on config options. For testing purposes, you might prefer to run a client on one of the testnet networks. [See overview of supported networks](/developers/docs/nodes-and-clients/#execution-clients). @@ -228,11 +228,11 @@ This section will guide you through starting execution clients. It only serves a - Specifies network to connect to, Mainnet in our examples - You can instead choose [one of testnets](/developers/docs/networks/) for preliminary testing of your setup - Defines data directory, where all the data including blockchain will be stored - - Make sure to substitute the path with a real one, e.g. pointing to your external drive + - Make sure to substitute the path with a real one, e.g., pointing to your external drive - Enables interfaces for communicating with the client - Including JSON-RPC and Engine API for communication with consensus client - Defines path to `jwtsecret` for authenticated API - - Make sure to substitute the example path with a real one which can be accessed by clients, e.g. `/tmp/jwtsecret` + - Make sure to substitute the example path with a real one which can be accessed by clients, e.g., `/tmp/jwtsecret` Please keep in mind that this is just a basic example, all other settings will be set to default. Pay attention to the documentation of each client to learn about default values, settings, and features. For more features, for example for running validators, monitoring, etc., please refer to the documentation of the specific client. @@ -321,7 +321,7 @@ The consensus client must be started with the right port configuration to establ The consensus client also needs the path to the execution client's `jwt-secret` in order to authenticate the RPC connection between them. Similar to execution examples above, each consensus client has a configuration flag which takes the jwt token file path as an argument. This must be consistent with the `jwtsecret` path provided to the execution client. -If you plan to run a validator, make sure to add a configuration flag specifying the Ethereum address of the fee recipient. This is where ether rewards for your validator accumulate. Each consensus client has an option, e.g. `--suggested-fee-recipient=0xabcd1`, that takes an Ethereum address as an argument. +If you plan to run a validator, make sure to add a configuration flag specifying the Ethereum address of the fee recipient. This is where ether rewards for your validator accumulate. Each consensus client has an option, e.g., `--suggested-fee-recipient=0xabcd1`, that takes an Ethereum address as an argument. When starting a Beacon Node on a testnet, you can save significant syncing time by using a public endpoint for [Checkpoint sync](https://notes.ethereum.org/@launchpad/checkpoint-sync). @@ -403,9 +403,9 @@ Look into [staking page](/staking) for an overview about staking options. Execution clients offer [RPC API endpoints](/developers/docs/apis/json-rpc/) that you can use to submit transactions, interact with or deploy smart contracts on the Ethereum network in various ways: -- Manually calling them with a suitable protocol (e.g. using `curl`) -- Attaching a provided console (e.g. `geth attach`) -- Implementing them in applications using web3 libraries, e.g. [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview), [ethers](https://github.com/ethers-io/ethers.js/) +- Manually calling them with a suitable protocol (e.g., using `curl`) +- Attaching a provided console (e.g., `geth attach`) +- Implementing them in applications using web3 libraries, e.g., [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview), [ethers](https://github.com/ethers-io/ethers.js/) Different clients have different implementations of the RPC endpoints. But there is a standard JSON-RPC which you can use with every client. For an overview [read the JSON-RPC docs](/developers/docs/apis/json-rpc/). Applications that need information from the Ethereum network can use this RPC. For example, popular wallet MetaMask lets you [connect to your own RPC endpoint](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node) which has strong privacy and security benefits. @@ -443,7 +443,7 @@ _This doesn't apply on consensus layer validator nodes._ Taking your node offlin #### Creating client services {#creating-client-services} -Consider creating a service to run your clients automatically on startup. For example, on Linux servers, good practice would be to create a service, e.g. with `systemd`, that executes the client with proper config, under a user with limited privileges and automatically restarts. +Consider creating a service to run your clients automatically on startup. For example, on Linux servers, good practice would be to create a service, e.g., with `systemd`, that executes the client with proper config, under a user with limited privileges and automatically restarts. #### Updating clients {#updating-clients} From 4497db207716f5658e439f531a5ca072cfbb13f1 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:30:30 -0500 Subject: [PATCH 198/212] hard stops on security/index --- public/content/security/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/security/index.md b/public/content/security/index.md index 446af365b67..efac8ffc085 100644 --- a/public/content/security/index.md +++ b/public/content/security/index.md @@ -137,7 +137,7 @@ In the run-up to [The Merge](/roadmap/merge/), scammers took advantage of the co Scammers may appear as "support", telling you that if you deposit your ETH, you will receive back 'ETH2'. There is no [official Ethereum support](/community/support/), and there is no new token. Never share your wallet seed phrase with anyone. -_Note: There are derivative tokens/tickers that may represent staked ETH (ie. rETH from Rocket Pool, stETH from Lido, ETH2 from Coinbase), but these are not something you need to "migrate to."_ +_Note: There are derivative tokens/tickers that may represent staked ETH (i.e., rETH from Rocket Pool, stETH from Lido, ETH2 from Coinbase), but these are not something you need to "migrate to."_ ### Phishing scams {#phishing-scams} From 8cccdaa5af6c36c3cb73c19bcb7df087d622cb70 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:30:44 -0500 Subject: [PATCH 199/212] hard stops on danksharding/inex --- public/content/translations/ga/roadmap/danksharding/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/roadmap/danksharding/index.md b/public/content/translations/ga/roadmap/danksharding/index.md index 460df63bac8..2e91792df21 100644 --- a/public/content/translations/ga/roadmap/danksharding/index.md +++ b/public/content/translations/ga/roadmap/danksharding/index.md @@ -53,7 +53,7 @@ When a rollup posts data in a blob, they provide a "commitment" that they post o -Más eol do dhuine na láithreacha randamacha a úsáideadh don tiomantas, is furasta dóibh iltéarmach nua a ghiniúint a oireann do na pointí sonracha sin (i.e. “imbhualadh”). Ciallaíonn sé seo go bhféadfadh siad sonraí a chur leis nó a bhaint den bhlob agus fós cruthúnas bailí a sholáthar. Chun é seo a chosc, in ionad na láithreacha rúnda iarbhír a thabhairt do na cruthaitheoirí, faigheann siad na láithreacha atá imfhillte i "mbosca dubh" cripteagrafach ag baint úsáide as cuair éilipseacha. Déanann siad seo na luachanna a scrobhadh go héifeachtach ar bhealach nach féidir na bunluachanna a aisiompú, ach le roinnt cruthaitheoirí agus fíoraitheoirí ailgéabar cliste fós is féidir leo iltéarmaí a mheas ag na pointí a léiríonn siad. +Más eol do dhuine na láithreacha randamacha a úsáideadh don tiomantas, is furasta dóibh iltéarmach nua a ghiniúint a oireann do na pointí sonracha sin (i.e., “imbhualadh”). Ciallaíonn sé seo go bhféadfadh siad sonraí a chur leis nó a bhaint den bhlob agus fós cruthúnas bailí a sholáthar. Chun é seo a chosc, in ionad na láithreacha rúnda iarbhír a thabhairt do na cruthaitheoirí, faigheann siad na láithreacha atá imfhillte i "mbosca dubh" cripteagrafach ag baint úsáide as cuair éilipseacha. Déanann siad seo na luachanna a scrobhadh go héifeachtach ar bhealach nach féidir na bunluachanna a aisiompú, ach le roinnt cruthaitheoirí agus fíoraitheoirí ailgéabar cliste fós is féidir leo iltéarmaí a mheas ag na pointí a léiríonn siad. From 6e54dabe71fb1bed58c9a037619c99a0fce291eb Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:31:04 -0500 Subject: [PATCH 200/212] hard stops on security/index --- public/content/translations/ga/security/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/ga/security/index.md b/public/content/translations/ga/security/index.md index ef92843a2ed..07e56fefac1 100644 --- a/public/content/translations/ga/security/index.md +++ b/public/content/translations/ga/security/index.md @@ -136,7 +136,7 @@ Sa tréimhse roimh [an gCumasc](/roadmap/merge/), bhain caimiléirí leas as an Féadfaidh caimiléirí iad féin a chur in aithne duit mar phearsanra "tacaíochta", ag insint duit má thaisceann tú do ETH, gheobhaidh tú 'ETH2' ar ais. Níl aon [tacaíocht oifigiúil Ethereum ann](/community/support/), agus níl aon chomhartha nua ann. Ná roinn frása síolta do sparán le haon duine. -_Nóta: Tá comharthaí díorthacha/tickers ann a d'fhéadfadh ionadaíocht a dhéanamh ar ETH geallta (ie. rETH ó Rocket Pool, stETH ó Lido, ETH2 ó Coinbase), ach ní gá iad seo a "aistriú chucu."_ +_Nóta: Tá comharthaí díorthacha/tickers ann a d'fhéadfadh ionadaíocht a dhéanamh ar ETH geallta (i.e., rETH ó Rocket Pool, stETH ó Lido, ETH2 ó Coinbase), ach ní gá iad seo a "aistriú chucu."_ ### Camscéimeanna fioscaireachta {#phishing-scams} From 9f87b0b3789832a6c0f8b5e6224eadfb4a5d0586 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:31:26 -0500 Subject: [PATCH 201/212] hard stops on whitepaper/index --- public/content/translations/ga/whitepaper/index.md | 10 +++++----- public/content/translations/pcm/whitepaper/index.md | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/public/content/translations/ga/whitepaper/index.md b/public/content/translations/ga/whitepaper/index.md index 267c837e249..1bc2a3d7f1c 100644 --- a/public/content/translations/ga/whitepaper/index.md +++ b/public/content/translations/ga/whitepaper/index.md @@ -247,7 +247,7 @@ Tá an blocshlabhra Ethereum cosúil le blocshlabhra Bitcoin ar go leor bealaí, 7. Bíodh `S_FINAL` ina `S[n]`, ach ag cur an luach saothair bloc a íocadh leis an mianadóir leis. 8. Seiceáil an bhfuil fréamh crainn Merkle an stáit `S_FINAL` cothrom leis an bhfréamh staid dheiridh a thugtar sa cheanntásc bloic. Má tá, tá an bloc bailí; ar shlí eile, níl sé bailí. -Bíonn cuma an-éifeachtach ar an gcur chuige ar an gcéad amharc, mar ní mór an staid iomlán a stóráil le gach bloc, ach i ndáiríre ba chóir don éifeachtacht a bheith inchomparáide le cuid Bitcoin. Is é an chúis atá leis ná go bhfuil an staid stóráilte i struchtúr an chrainn, agus tar éis gach bloc ní gá ach cuid bheag den chrann a athrú. Mar sin, go ginearálta, idir dhá bhloc in aice le chéile, ba chóir go mbeadh formhór mór an chrainn mar an gcéanna, agus dá bhrí sin is féidir na sonraí a stóráil uair amháin agus tagairt a dhéanamh dóibh faoi dhó le pointeoirí (ie. haiseanna de fho-chrainn). Úsáidtear crann speisialta ar a dtugtar "crann Patricia" chun é seo a bhaint amach, le modhnú ar choincheap an chrainn Merkle a cheadaíonn nóid a chur isteach agus a scriosadh, agus ní hamháin a athrú, go héifeachtach. Ina theannta sin, toisc go bhfuil an fhaisnéis staide go léir mar chuid den bhloc deireanach, níl aon ghá le stair iomlán an bhlocshlabhra a stóráil - straitéis ar féidir, dá bhféadfaí é a chur i bhfeidhm ar Bitcoin, a ríomh chun coigilteas 5-20x a sholáthar sa spás. +Bíonn cuma an-éifeachtach ar an gcur chuige ar an gcéad amharc, mar ní mór an staid iomlán a stóráil le gach bloc, ach i ndáiríre ba chóir don éifeachtacht a bheith inchomparáide le cuid Bitcoin. Is é an chúis atá leis ná go bhfuil an staid stóráilte i struchtúr an chrainn, agus tar éis gach bloc ní gá ach cuid bheag den chrann a athrú. Mar sin, go ginearálta, idir dhá bhloc in aice le chéile, ba chóir go mbeadh formhór mór an chrainn mar an gcéanna, agus dá bhrí sin is féidir na sonraí a stóráil uair amháin agus tagairt a dhéanamh dóibh faoi dhó le pointeoirí (i.e., haiseanna de fho-chrainn). Úsáidtear crann speisialta ar a dtugtar "crann Patricia" chun é seo a bhaint amach, le modhnú ar choincheap an chrainn Merkle a cheadaíonn nóid a chur isteach agus a scriosadh, agus ní hamháin a athrú, go héifeachtach. Ina theannta sin, toisc go bhfuil an fhaisnéis staide go léir mar chuid den bhloc deireanach, níl aon ghá le stair iomlán an bhlocshlabhra a stóráil - straitéis ar féidir, dá bhféadfaí é a chur i bhfeidhm ar Bitcoin, a ríomh chun coigilteas 5-20x a sholáthar sa spás. Ceist a chuirtear go coitianta is ea "cá" ritear cód conartha, i dtéarmaí crua-earraí fisiceacha. Tá freagra simplí air seo: tá an próiseas maidir le cód conartha a rith mar chuid den sainmhíniú ar fheidhm aistrithe na staide, atá mar chuid den algartam bailíochtaithe bloc, mar sin má chuirtear idirbheart isteach sa bhloc `B` an cód déanfaidh gach nód, anois agus amach anseo, a dhéanann an bloc `B` a íoslódáil agus a bhailíochtú an rith a bheidh déanta ag an idirbheart sin. @@ -281,7 +281,7 @@ Agus an comhábhar ríthábhachtach sin á chur san áireamh, is mar seo a leana 3. Taifead an luach USD de 1000 éitear, arna ríomh trí cheist a chur faoin gconradh beathaithe sonraí, i stóráil, abair gurb é seo $x. 4. Tar éis 30 lá, lig do A nó B an conradh a “athghníomhachtú” chun éitear de luach $x (arna ríomh tríd an gconradh fothaithe sonraí a cheistiú arís chun an praghas nua a fháil) a sheoladh chuig A agus an chuid eile chuig B. -Bheadh ​​cumas suntasach ag conradh den sórt sin i criptea-thráchtáil. Ceann de na fadhbanna is mó a luadh faoi criptea-airgeadra is ea an fíric go bhfuil sé luaineach; cé go bhféadfadh go mbeadh go leor úsáideoirí agus díoltóirí ag iarraidh an tslándáil agus an áisiúlacht chun déileáil le sócmhainní cripteagrafacha, níor mhian le go leor acu aghaidh a thabhairt ar an ionchas sin 23% de luach a gcistí a chailleadh in aon lá amháin. Go dtí seo, is é an réiteach is coitianta a mholtar ná sócmhainní arna dtacú ag eisitheoirí; is é an smaoineamh go gcruthaíonn eisitheoir fo-airgeadra ina bhfuil sé de cheart aige aonaid a eisiúint agus a chúlghairm, agus aonad amháin den airgeadra a sholáthar d’aon duine a sholáthraíonn (as líne) aonad amháin de bhunsócmhainn shonraithe dóibh (eg. ór , USD). Geallann an t-eisitheoir ansin aonad amháin den bhunsócmhainn a sholáthar do dhuine ar bith a sheolann aonad amháin den tsócmhainn criptea ar ais. Ceadaíonn an mheicníocht seo aon sócmhainn neamh-chripteagrafach a "ardú" isteach i sócmhainn chripteagrafach, ar choinníoll gur féidir muinín a chur san eisitheoir. +Bheadh ​​cumas suntasach ag conradh den sórt sin i criptea-thráchtáil. Ceann de na fadhbanna is mó a luadh faoi criptea-airgeadra is ea an fíric go bhfuil sé luaineach; cé go bhféadfadh go mbeadh go leor úsáideoirí agus díoltóirí ag iarraidh an tslándáil agus an áisiúlacht chun déileáil le sócmhainní cripteagrafacha, níor mhian le go leor acu aghaidh a thabhairt ar an ionchas sin 23% de luach a gcistí a chailleadh in aon lá amháin. Go dtí seo, is é an réiteach is coitianta a mholtar ná sócmhainní arna dtacú ag eisitheoirí; is é an smaoineamh go gcruthaíonn eisitheoir fo-airgeadra ina bhfuil sé de cheart aige aonaid a eisiúint agus a chúlghairm, agus aonad amháin den airgeadra a sholáthar d’aon duine a sholáthraíonn (as líne) aonad amháin de bhunsócmhainn shonraithe dóibh (e.g., ór , USD). Geallann an t-eisitheoir ansin aonad amháin den bhunsócmhainn a sholáthar do dhuine ar bith a sheolann aonad amháin den tsócmhainn criptea ar ais. Ceadaíonn an mheicníocht seo aon sócmhainn neamh-chripteagrafach a "ardú" isteach i sócmhainn chripteagrafach, ar choinníoll gur féidir muinín a chur san eisitheoir. Go praiticiúil, áfach, ní bhíonn eisitheoirí iontaofa i gcónaí, agus i gcásanna áirithe bíonn an bonneagar baincéireachta ró-lag, nó ró-naimhdeach, le go mbeadh a leithéid de sheirbhísí ann. Soláthraíonn díorthaigh airgeadais rogha eile. Anseo, in ionad eisitheoir aonair a sholáthraíonn cistí mar chúltaca do shócmhainn, imríonn margadh díláraithe amhantraithe, a chuireann geall go n-ardóidh praghas sócmhainn tagartha cripteagrafach (m. sh. ETH). Murab ionann agus eisitheoirí, níl aon rogha ag amhantraithe mainneachtain a dhéanamh ar a dtaobh féin den mhargadh toisc go gcoimeádann an conradh fálaithe a gcuid cistí in eascró. Tabhair faoi deara nach bhfuil an cur chuige seo díláraithe go hiomlán, toisc go bhfuil foinse iontaofa fós ag teastáil chun an ticeoir praghais a sholáthar, cé gur féidir a mhaíomh go fóill gur feabhas ollmhór é seo maidir le ceanglais bhonneagair a laghdú (murab ionann agus a bheith i d’eisitheoir, níl aon cheadúnais ag teastáil chun fotha praghais a eisiúint agus is dócha gur féidir iad a chatagóiriú mar shaorchaint) agus an poitéinseal calaoise a laghdú. @@ -335,7 +335,7 @@ De ghnáth, is leor 1% in aghaidh an lae do Alice, agus má tá Alice ag iarraid **4. Eascró cliste le síniú iolrach**. Ceadaíonn Bitcoin conarthaí idirbhirt le síniú iolrach mar ar féidir, mar shampla, le trí cinn as cúig eochracha ar leith na cistí a chaitheamh. Ceadaíonn Ethereum níos mó gráinneachta; mar shampla, is féidir le ceathrar as gach cúigear gach rud a chaitheamh, is féidir le triúr as gach cúigear suas le 10% a chaitheamh in aghaidh an lae, agus is féidir le beirt as gach cúigear suas le 0.5% a chaitheamh in aghaidh an lae. Ina theannta sin, tá Ethereum multisig aisioncronach - is féidir le dhá pháirtí a gcuid sínithe a chlárú ar an mblocshlabhra ag amanna éagsúla agus seolfaidh an síniú deireanach an t-idirbheart go huathoibríoch. -**5. Néalríomhaireacht**. Is féidir an teicneolaíocht EVM a úsáid freisin chun timpeallacht ríomhaireachta infhíoraithe a chruthú, rud a ligeann d’úsáideoirí iarraidh ar dhaoine eile ríomhanna a dhéanamh agus ansin cruthúnais a iarraidh go roghnach go ndearnadh ríomhanna ag seicphointí roghnaithe go randamach i gceart. Ceadaíonn sé seo margadh néalríomhaireachta a chruthú inar féidir le haon úsáideoir a bheith rannpháirteach lena ríomhaire deisce, glúine nó freastalaí speisialaithe, agus is féidir spotseiceáil mar aon le taiscí slándála a úsáid lena chinntiú go bhfuil an córas iontaofa (ie. ní féidir le nóid caimiléireacht a dhéanamh go brabúsach). Cé go mb’fhéidir nach mbeadh a leithéid de chóras oiriúnach do gach tasc; ní féidir tascanna a éilíonn ardleibhéal cumarsáide idirphróisis, mar shampla, a dhéanamh go héasca ar scamall mór nód. Tá tascanna eile, áfach, i bhfad níos éasca a chomhthreomharú; is furasta tionscadail mar SETI@home, folding@home agus halgartaim ghéiniteacha a chur i bhfeidhm ar bharr ardán dá leithéid. +**5. Néalríomhaireacht**. Is féidir an teicneolaíocht EVM a úsáid freisin chun timpeallacht ríomhaireachta infhíoraithe a chruthú, rud a ligeann d’úsáideoirí iarraidh ar dhaoine eile ríomhanna a dhéanamh agus ansin cruthúnais a iarraidh go roghnach go ndearnadh ríomhanna ag seicphointí roghnaithe go randamach i gceart. Ceadaíonn sé seo margadh néalríomhaireachta a chruthú inar féidir le haon úsáideoir a bheith rannpháirteach lena ríomhaire deisce, glúine nó freastalaí speisialaithe, agus is féidir spotseiceáil mar aon le taiscí slándála a úsáid lena chinntiú go bhfuil an córas iontaofa (i.e., ní féidir le nóid caimiléireacht a dhéanamh go brabúsach). Cé go mb’fhéidir nach mbeadh a leithéid de chóras oiriúnach do gach tasc; ní féidir tascanna a éilíonn ardleibhéal cumarsáide idirphróisis, mar shampla, a dhéanamh go héasca ar scamall mór nód. Tá tascanna eile, áfach, i bhfad níos éasca a chomhthreomharú; is furasta tionscadail mar SETI@home, folding@home agus halgartaim ghéiniteacha a chur i bhfeidhm ar bharr ardán dá leithéid. **6. Cearrbhachas idir piaraí**. Is féidir líon ar bith de phrótacail chearrbhachais idir comhghleacaithe, mar shampla Frank Stajano agus Richard Clayton [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf), a chur i bhfeidhm ar bhlocshlabhra Ethereum. Is é an prótacal cearrbhachais is simplí i ndáiríre ná conradh le haghaidh difríochta ar an gcéad bhloc haise eile, agus is féidir prótacail níos airde a thógáil as sin, ag cruthú seirbhísí cearrbhachais le táillí gar-nialas nach bhfuil ar a gcumas caimiléireacht. @@ -371,7 +371,7 @@ Mar sin féin, mar a tharlaíonn, cealaíonn an locht sa mheicníocht atá bunai 1. Is é an toradh a bhíonn ar idirbheart ná oibríochtaí `k`, ag tairiscint an luach saothair `kR` do mhianadóir ar bith a chuimsíonn é nuair a shocraíonn an seoltóir `R` agus tá `k` agus `R` (beagán) le feiceáil ag an mianadóir roimh ré. 2. Tá costas próiseála `C` ag oibríocht ar aon nód (. i. tá an éifeachtacht chéanna ag gach nód) -3. Tá nóid mhianadóireachta `N` ann, gach ceann acu ar cóimhéid le cumhacht próiseála (ie. `1/N` den iomlán) +3. Tá nóid mhianadóireachta `N` ann, gach ceann acu ar cóimhéid le cumhacht próiseála (i.e., `1/N` den iomlán) 4. Níl aon nóid iomlána neamh-mhianadóireachta ann. Bheadh ​​​​mianadóir sásta idirbheart a phróiseáil má tá an luach saothair ionchais níos mó ná an costas. Mar sin, is é `kR/N` an luach saothair a bhfuiltear ag súil leis toisc go bhfuil seans `1/N` ag an mianadóir an chéad bhloc eile a phróiseáil, agus is é an costas próiseála don mhianadóir ` kC`. Mar sin, áireoidh mianadóirí idirbhearta ina bhfuil `kR/N > kC`, nó `R > NC`. Tabhair faoi deara gurb é `R` an táille in aghaidh na hoibríochta a sholáthraíonn an seoltóir, agus mar sin tá teorainn níos ísle ar an sochar a fhaigheann an seoltóir ón idirbheart, agus is é `NC` an costas don líonra iomlán le chéile chun oibríocht a phróiseáil. Dá bhrí sin, tá dreasacht ag mianadóirí gan ach na hidirbhearta sin a sháraíonn an sochar fónta iomlán ná an costas a chur san áireamh. @@ -460,7 +460,7 @@ Tabhair faoi deara, sa todhchaí, is dócha go n-aistreoidh Ethereum go múnla c Oibríonn an t-algartam mianadóireachta Bitcoin trí iarraidh ar mhianadóirí SHA256 a ríomh ar leaganacha beagán modhnaithe den cheannteideal bloc na milliúin uaireanta arís agus arís eile, go dtí go dtiocfaidh nód amháin suas le leagan a bhfuil a hais níos lú ná an sprioc (thart ar 2192 faoi láthair). Mar sin féin, tá an t-algartam mianadóireachta seo i mbaol ó dhá chineál láraithe. Sa chéad dul síos, tá an t-éiceachóras mianadóireachta faoi cheannas ASICs (ciorcaid iomlánaithe a bhaineann go sonrach le feidhm) anois, sliseanna ríomhaire atá deartha le haghaidh tasc sonrach mianadóireachta Bitcoin,, agus mar sin na mílte uaire níos éifeachtaí. Ciallaíonn sé seo nach bhfuil mianadóireacht Bitcoin ina shaothrú an-díláraithe agus cothromaíoch a thuilleadh, éilíonn sé na milliúin dollar caipitil le bheith rannpháirteach go héifeachtach ann. Sa dara háit, ní dhéanann an chuid is mó de na mianadóirí Bitcoin bailíochtú bloc go háitiúil i ndáiríre; ina ionad sin, bíonn siad ag brath ar chomhthiomsú mianadóireachta láraithe chun na ceannteidil bloc a sholáthar. D’fhéadfaí a mhaíomh go bhfuil an fhadhb seo níos measa: ó scríobhadh an méid seo, rialaíonn na trí linnte mianadóireachta is mó go hindíreach thart ar 50% den chumhacht próiseála i líonra Bitcoin, cé go maolaítear é seo toisc gur féidir le mianadóirí aistriú chuig linnte mianadóireachta eile má dhéanann linn nó comhaltas mianadóireachta iarracht ionsaí 51%. -Is í intinn Ethereum faoi láthair algartam mianadóireachta a úsáid ina n-éilítear ar mhianadóirí sonraí randamacha a fháil ón staid, roinnt idirbheart a roghnaíodh go randamach a ríomh ó na bloic N deiridh sa bhlocshlabhra, agus hais an toraidh a sheoladh ar ais. Tá dhá bhuntáiste thábhachtacha ag baint leis seo. Sa chéad áit, is féidir go n-áireofaí ríomh de chineál ar bith i gconarthaí Ethereum, mar sin bheadh ​​​​ASIC Ethereum go bunúsach ina ASIC le haghaidh ríomh ginearálta - ie. LAP níos fearr. Ar an dara dul síos, éilíonn mianadóireacht rochtain ar an mblocshlabhra iomlán, rud a chuireann iallach ar mhianadóirí an blocshlabhra iomlán a stóráil agus a bheith in ann gach idirbheart a fhíorú ar a laghad. Cuireann sé seo deireadh leis an ngá atá le linnte mianadóireachta láraithe; cé gur féidir le linnte mianadóireachta freastal fós ar an ról dlisteanach a bhaineann le randamacht dáileadh luach saothair a chothromú, is féidir freastal chomh maith céanna ar an bhfeidhm seo trí chomhthiomsuithe piara le piaraí nach bhfuil aon smacht lárnach acu. +Is í intinn Ethereum faoi láthair algartam mianadóireachta a úsáid ina n-éilítear ar mhianadóirí sonraí randamacha a fháil ón staid, roinnt idirbheart a roghnaíodh go randamach a ríomh ó na bloic N deiridh sa bhlocshlabhra, agus hais an toraidh a sheoladh ar ais. Tá dhá bhuntáiste thábhachtacha ag baint leis seo. Sa chéad áit, is féidir go n-áireofaí ríomh de chineál ar bith i gconarthaí Ethereum, mar sin bheadh ​​​​ASIC Ethereum go bunúsach ina ASIC le haghaidh ríomh ginearálta - i.e., LAP níos fearr. Ar an dara dul síos, éilíonn mianadóireacht rochtain ar an mblocshlabhra iomlán, rud a chuireann iallach ar mhianadóirí an blocshlabhra iomlán a stóráil agus a bheith in ann gach idirbheart a fhíorú ar a laghad. Cuireann sé seo deireadh leis an ngá atá le linnte mianadóireachta láraithe; cé gur féidir le linnte mianadóireachta freastal fós ar an ról dlisteanach a bhaineann le randamacht dáileadh luach saothair a chothromú, is féidir freastal chomh maith céanna ar an bhfeidhm seo trí chomhthiomsuithe piara le piaraí nach bhfuil aon smacht lárnach acu. Tá an tsamhail seo gan tástáil, agus d'fhéadfadh deacrachtaí a bheith ann maidir le leas iomlán a bhaint as optamuithe cliste áirithe a sheachaint agus rith conartha á úsáid mar algartam mianadóireachta. Gné an-suimiúil amháin den algartam seo, áfach, is ea go gceadaíonn sé do dhuine ar bith "an tobar a nimhiú", trí líon mór conarthaí a thabhairt isteach sa bhlocshlabhra atá deartha go sonrach chun ASICanna áirithe a chosc. Tá dreasachtaí eacnamaíocha ann do mhonaróirí ASIC cleas den sórt sin a úsáid chun ionsaí a dhéanamh ar a chéile. Mar sin, is réiteach oiriúnaitheach eacnamaíoch daonna é an réiteach atá á fhorbairt againn ar deireadh seachas réiteach teicniúil amháin. diff --git a/public/content/translations/pcm/whitepaper/index.md b/public/content/translations/pcm/whitepaper/index.md index 7036ea42a2a..02c220dd817 100644 --- a/public/content/translations/pcm/whitepaper/index.md +++ b/public/content/translations/pcm/whitepaper/index.md @@ -135,7 +135,7 @@ Even witout any extenshons, di Bitcoin protokol akshualy dey facilitate wik vash Haueva, di skripting languaj as dem run am for Bitcoin get many limitashons: - **Lack of Turing-completeness** - dat na to say, while e get big subset of komputashon wey di Bitcoin skripting languaj dey support, en nor almost support efritin. Di main category wey dey miss na loops. Dem dey do dis to afoid infinite loops during transakshon verifikashon; theoretikaly dem nor fit ridus big palava for skript programas, sinse any loop fit simulate wen anybodi do di basik kode many taims wit one if statement, but im nor lead to skripts wey get very space-inefishient. For eksampol, to run difren elliptik kurve signashure algorithm go fit rikwaya 256 repeated multiplikashon rounds all put one by one for di kode. -- **Value-blindness** - wey nor dey for UTXO skript to giv fine-grained kontrol ova di amount wey dey fit witdraw. For eksampol, one pawaful yus kase of orakol kontract go bi hedging kontract, wia A and B go put $1000 worth of BTC and afta 30 days di skript go send $1000 worth of BTC to A and di rest to B. Dis one go rikwaya orakol make im ditamin di value of 1 BTC for USD, but even den e bi big growth for terms of trust and infrastrukshure rikwayament ova di fully sentralized solushons wey dey afailabol nau. But bikos dem UTXO na all-or-nothing, di only way wey e fit get dis na thru very unstabol hack wey go make di pesin get UTXO of difren amount (eg. one UTXO of 2k for efri k up to 30) and having di orakol pick wich UTXO e go send give A and wich one e go send giv B. +- **Value-blindness** - wey nor dey for UTXO skript to giv fine-grained kontrol ova di amount wey dey fit witdraw. For eksampol, one pawaful yus kase of orakol kontract go bi hedging kontract, wia A and B go put $1000 worth of BTC and afta 30 days di skript go send $1000 worth of BTC to A and di rest to B. Dis one go rikwaya orakol make im ditamin di value of 1 BTC for USD, but even den e bi big growth for terms of trust and infrastrukshure rikwayament ova di fully sentralized solushons wey dey afailabol nau. But bikos dem UTXO na all-or-nothing, di only way wey e fit get dis na thru very unstabol hack wey go make di pesin get UTXO of difren amount (e.g., one UTXO of 2k for efri k up to 30) and having di orakol pick wich UTXO e go send give A and wich one e go send giv B. - **Lack of state** - UTXO fit dey spend abi nor spend. Oportunity nor dey for multi-stage kontracts abi skripts wey dey kip any oda internal state biyond dat. Dis one dey make am hard to make multi-stage opshons kontracts, disentralized ekshanj offas abi two-stage cryptographic komitment protokols (wey dey necessary for sekure komputashonal bountis). Im also mean sey dem fiy only yus UTXO to build simpol, kontracts wey go work just wons. Im nor fit build more komplex "stateful" kontracts laik disentralized organizashons, and e dey make meta-protokols hard to run. Binary state kombine wit value-blindness also mean sey anoda important aplikashon, witdrawal limits, nor dey posibol. - **Blockchain-blindness** - UTXO dey blind to blockchain data laik di nonce, di taimstamp and block hash wey don hapun bifor. Dis one dey limit aplikashons for gambol wella, and plenti oda kategoris, by blokin di skripting languaj of important sorse of randomness wey fit hapun. From 5e3f2101d65bb9815fa86bf56b3bb3d7ebc7010a Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:31:45 -0500 Subject: [PATCH 202/212] hard stops on security/index --- public/content/translations/pcm/security/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/translations/pcm/security/index.md b/public/content/translations/pcm/security/index.md index 063bb9e6980..18c7de721bb 100644 --- a/public/content/translations/pcm/security/index.md +++ b/public/content/translations/pcm/security/index.md @@ -136,7 +136,7 @@ For di run-up to [Di Merge](/roadmap/merge/), skammas don take advantaj of di ko Skammas fit appia as "suppot", as dem dey tell yu dat if yu deposit yor ETH, yu go risiv back 'ETH2'. Nor [official Ethereum suppot](/community/support/) dey, and nor new token dey. Neva shia yor wallet seed fraiz wit anyone. -_Note: E get some derivative tokens/tickers wey fit reprisent ETH wey dem stake (ie. rETH from Rocket Pool, stETH from Lido, ETH2 from Coinbase), but dis nor bi sontin yu nid to "migrate to."_ +_Note: E get some derivative tokens/tickers wey fit reprisent ETH wey dem stake (i.e., rETH from Rocket Pool, stETH from Lido, ETH2 from Coinbase), but dis nor bi sontin yu nid to "migrate to."_ ### Phishing skams {#phishing-scams} From de41d892cb7ef1683fb8f0ce8254ad7c2bed6f69 Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:32:04 -0500 Subject: [PATCH 203/212] hard stops on zero-knowledge-proofs/index --- public/content/translations/ga/zero-knowledge-proofs/index.md | 4 ++-- .../content/translations/pcm/zero-knowledge-proofs/index.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/public/content/translations/ga/zero-knowledge-proofs/index.md b/public/content/translations/ga/zero-knowledge-proofs/index.md index 449f8e2ecd9..60752f08aa3 100644 --- a/public/content/translations/ga/zero-knowledge-proofs/index.md +++ b/public/content/translations/ga/zero-knowledge-proofs/index.md @@ -88,7 +88,7 @@ Mar shampla, braitheann [meicníochtaí cuardratacha cistiúcháin](https://www. Using onchain voting makes quadratic funding susceptible to collusion: blockchain transactions are public, so bribers can inspect a bribee’s onchain activity to see how they “voted”. Ar an mbealach seo cuirtear stop le maoiniú cuadratach a bheith ina mhodh éifeachtach chun cistí a leithdháileadh bunaithe ar roghanna comhiomlánaithe an phobail. -Fortunately, newer solutions such as MACI (Minimum Anti-Collusion Infrastructure) are using zero-knowledge proofs to make onchain voting (eg., quadratic funding mechanisms) resistant to bribery and collusion. Is sraith de chonarthaí cliste agus scripteanna é MACI a ligeann do riarthóir lárnach (ar a dtugtar "comhordaitheoir") vótaí agus torthaí a chomhiomlánú _gan_ sonraí a nochtadh faoin gcaoi ar vótáil gach duine. Mar sin féin, is féidir a fhíorú go fóill gur comhairíodh na vótaí i gceart, nó a dheimhniú gur ghlac duine ar leith páirt sa bhabhta vótála. +Fortunately, newer solutions such as MACI (Minimum Anti-Collusion Infrastructure) are using zero-knowledge proofs to make onchain voting (e.g., quadratic funding mechanisms) resistant to bribery and collusion. Is sraith de chonarthaí cliste agus scripteanna é MACI a ligeann do riarthóir lárnach (ar a dtugtar "comhordaitheoir") vótaí agus torthaí a chomhiomlánú _gan_ sonraí a nochtadh faoin gcaoi ar vótáil gach duine. Mar sin féin, is féidir a fhíorú go fóill gur comhairíodh na vótaí i gceart, nó a dheimhniú gur ghlac duine ar leith páirt sa bhabhta vótála. #### Conas a oibríonn MACI le cruthúnais nial-eolais? {#how-maci-works-with-zk-proofs} @@ -140,7 +140,7 @@ Sampla maith a léiríonn an chaoi a n-oibríonn cruthúnais idirghníomhacha n Cé go raibh an cruthú réabhlóideach, bhí an promhú idirghníomhach teoranta ó thaobh úsáidí de toisc go raibh gá leis an dá pháirtí a bheith ar fáil agus idirghníomhú arís agus arís eile. Fiú dá mbeadh fíoraitheoir cinnte faoi ionracas an phromhadóra, ní bheadh ​​an cruthúnas ar fáil le haghaidh fíorú neamhspleách (chun cruthúnais nua a ríomh bhí gá le sraith nua teachtaireachtaí idir an promhadóir agus an fíoraitheoir). -Chun an fhadhb seo a réiteach, mhol Manuel Blum, Paul Feldman, agus Silvio Micali na chéad [cruthúnais nial-eolais neamh-idirghníomhach](https://dl.acm.org/doi/10.1145/62212.62222) áit a bhfuil eochair roinnte ag an seanfhocal agus ag an bhfíoraitheoir. Ligeann sé seo don chruthaitheoir a gcuid eolais ar roinnt faisnéise a léiriú (i.e. finné) gan an fhaisnéis féin a sholáthar. +Chun an fhadhb seo a réiteach, mhol Manuel Blum, Paul Feldman, agus Silvio Micali na chéad [cruthúnais nial-eolais neamh-idirghníomhach](https://dl.acm.org/doi/10.1145/62212.62222) áit a bhfuil eochair roinnte ag an seanfhocal agus ag an bhfíoraitheoir. Ligeann sé seo don chruthaitheoir a gcuid eolais ar roinnt faisnéise a léiriú (i.e., finné) gan an fhaisnéis féin a sholáthar. Murab ionann agus cruthúnais idirghníomhacha, níor theastaigh ach babhta cumarsáide amháin idir rannpháirtithe (promhadóir agus fíoraitheoir) le cruthúnais neamh-idirghníomhacha. Cuireann an promhadóir an fhaisnéis rúnda ar aghaidh chuig algartam speisialta chun cruthúnas nial-eolais a ríomh. Seoltar an cruthúnas seo chuig an bhfíoraitheoir, a sheiceálann go bhfuil an fhaisnéis rúnda ar eolas ag an bpromhadóir trí úsáid a bhaint as algartam eile. diff --git a/public/content/translations/pcm/zero-knowledge-proofs/index.md b/public/content/translations/pcm/zero-knowledge-proofs/index.md index 6c987da7952..08d13538971 100644 --- a/public/content/translations/pcm/zero-knowledge-proofs/index.md +++ b/public/content/translations/pcm/zero-knowledge-proofs/index.md @@ -88,7 +88,7 @@ For eksampol, [quadratic funding mechanisms](https://www.radicalxchange.org/conc To dey dey on-chain voting dey make quadratic funding dey eksposed to kollushon; blockchains dey publik, so pesin wey dey bribe fit sheck hau pesin wey kollet bribe for on-chain aktivity dey "vote". Dis way quadratic funding nor bi ogbonge way to dey allokate funds base on di aggregate komunity dem prifa. -Gud tin bi sey, solushons wey new pass laik MACI (Minimum Anti-Collusion Infrastructure) dey yus zero-knowlej prufs to make on-chain voting (eg., quadratic funding mechanisms) dey resist bribe and kollushon. MACI na one set of smart kontracts and skripts wey dey allow one sentral administrator (wey dem koll "koordinator") to gada vote kon tally rizuts _witout_ showin spesifik on hau ish pesin don vote. Even so, im still dey posibol to verify sey dem don kount di vote wella, abi konfam sey one patikular pesin don patisipate for di voting round. +Gud tin bi sey, solushons wey new pass laik MACI (Minimum Anti-Collusion Infrastructure) dey yus zero-knowlej prufs to make on-chain voting (e.g., quadratic funding mechanisms) dey resist bribe and kollushon. MACI na one set of smart kontracts and skripts wey dey allow one sentral administrator (wey dem koll "koordinator") to gada vote kon tally rizuts _witout_ showin spesifik on hau ish pesin don vote. Even so, im still dey posibol to verify sey dem don kount di vote wella, abi konfam sey one patikular pesin don patisipate for di voting round. #### Hau MACI dey wok wit zero-knowlej prufs? {#how-maci-works-with-zk-proofs} From 4a91011a807a8bfdeec117713e7984b5bfbb07fb Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:32:19 -0500 Subject: [PATCH 204/212] hard stops zero-knowledge-proofs/index --- public/content/zero-knowledge-proofs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/public/content/zero-knowledge-proofs/index.md b/public/content/zero-knowledge-proofs/index.md index e71a5b592c7..0bb04dc38a3 100644 --- a/public/content/zero-knowledge-proofs/index.md +++ b/public/content/zero-knowledge-proofs/index.md @@ -94,7 +94,7 @@ For example, [quadratic funding mechanisms](https://www.radicalxchange.org/conce Using onchain voting makes quadratic funding susceptible to collusion: blockchain transactions are public, so bribers can inspect a bribee’s onchain activity to see how they “voted”. This way quadratic funding ceases to be an effective means for allocating funds based on the aggregated preferences of the community. -Fortunately, newer solutions such as MACI (Minimum Anti-Collusion Infrastructure) are using zero-knowledge proofs to make onchain voting (eg., quadratic funding mechanisms) resistant to bribery and collusion. MACI is a set of smart contracts and scripts that allow a central administrator (called a "coordinator") to aggregate votes and tally results _without_ revealing specifics on how each individual voted. Even so, it is still possible to verify that the votes were counted properly, or confirm that a particular individual participated in the voting round. +Fortunately, newer solutions such as MACI (Minimum Anti-Collusion Infrastructure) are using zero-knowledge proofs to make onchain voting (e.g., quadratic funding mechanisms) resistant to bribery and collusion. MACI is a set of smart contracts and scripts that allow a central administrator (called a "coordinator") to aggregate votes and tally results _without_ revealing specifics on how each individual voted. Even so, it is still possible to verify that the votes were counted properly, or confirm that a particular individual participated in the voting round. #### How does MACI work with zero-knowledge proofs? {#how-maci-works-with-zk-proofs} From b92cff1672fd7aee07419f1c1146a75d470773bd Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:32:31 -0500 Subject: [PATCH 205/212] hard stops on whitepaper/index --- public/content/whitepaper/index.md | 36 +++++++++++++++--------------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/public/content/whitepaper/index.md b/public/content/whitepaper/index.md index 287edab98bb..1a2a6cefd0e 100644 --- a/public/content/whitepaper/index.md +++ b/public/content/whitepaper/index.md @@ -78,7 +78,7 @@ The first half of the first step prevents transaction senders from spending coin ![Ethereum blocks](./ethereum-blocks.png) -If we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described, using a centralized server's hard drive to keep track of the state. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks". The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (ie. hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, "blockchain" that constantly updates to represent the latest state of the Bitcoin ledger. +If we had access to a trustworthy centralized service, this system would be trivial to implement; it could simply be coded exactly as described, using a centralized server's hard drive to keep track of the state. However, with Bitcoin we are trying to build a decentralized currency system, so we will need to combine the state transaction system with a consensus system in order to ensure that everyone agrees on the order of transactions. Bitcoin's decentralized consensus process requires nodes in the network to continuously attempt to produce packages of transactions called "blocks". The network is intended to produce roughly one block every ten minutes, with each block containing a timestamp, a nonce, a reference to (i.e., hash of) the previous block and a list of all of the transactions that have taken place since the previous block. Over time, this creates a persistent, ever-growing, "blockchain" that constantly updates to represent the latest state of the Bitcoin ledger. The algorithm for checking if a block is valid, expressed in this paradigm, is as follows: @@ -135,7 +135,7 @@ Even without any extensions, the Bitcoin protocol actually does facilitate a wea However, the scripting language as implemented in Bitcoin has several important limitations: - **Lack of Turing-completeness** - that is to say, while there is a large subset of computation that the Bitcoin scripting language supports, it does not nearly support everything. The main category that is missing is loops. This is done to avoid infinite loops during transaction verification; theoretically it is a surmountable obstacle for script programmers, since any loop can be simulated by simply repeating the underlying code many times with an if statement, but it does lead to scripts that are very space-inefficient. For example, implementing an alternative elliptic curve signature algorithm would likely require 256 repeated multiplication rounds all individually included in the code. -- **Value-blindness** - there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn. For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B. This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now. However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (eg. one UTXO of 2k for every k up to 30) and having the oracle pick which UTXO to send to A and which to B. +- **Value-blindness** - there is no way for a UTXO script to provide fine-grained control over the amount that can be withdrawn. For example, one powerful use case of an oracle contract would be a hedging contract, where A and B put in $1000 worth of BTC and after 30 days the script sends $1000 worth of BTC to A and the rest to B. This would require an oracle to determine the value of 1 BTC in USD, but even then it is a massive improvement in terms of trust and infrastructure requirement over the fully centralized solutions that are available now. However, because UTXO are all-or-nothing, the only way to achieve this is through the very inefficient hack of having many UTXO of varying denominations (e.g., one UTXO of 2k for every k up to 30) and having the oracle pick which UTXO to send to A and which to B. - **Lack of state** - UTXO can either be spent or unspent; there is no opportunity for multi-stage contracts or scripts which keep any other internal state beyond that. This makes it hard to make multi-stage options contracts, decentralized exchange offers or two-stage cryptographic commitment protocols (necessary for secure computational bounties). It also means that UTXO can only be used to build simple, one-off contracts and not more complex "stateful" contracts such as decentralized organizations, and makes meta-protocols difficult to implement. Binary state combined with value-blindness also mean that another important application, withdrawal limits, is impossible. - **Blockchain-blindness** - UTXO are blind to blockchain data such as the nonce, the timestamp and previous block hash. This severely limits applications in gambling, and several other categories, by depriving the scripting language of a potentially valuable source of randomness. @@ -193,7 +193,7 @@ Note that the gas allowance assigned by a transaction or contract applies to the The Ethereum state transition function, `APPLY(S,TX) -> S'` can be defined as follows: -1. Check if the transaction is well-formed (ie. has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error. +1. Check if the transaction is well-formed (i.e., has the right number of values), the signature is valid, and the nonce matches the nonce in the sender's account. If not, return an error. 2. Calculate the transaction fee as `STARTGAS * GASPRICE`, and determine the sending address from the signature. Subtract the fee from the sender's account balance and increment the sender's nonce. If there is not enough balance to spend, return an error. 3. Initialize `GAS = STARTGAS`, and take off a certain quantity of gas per byte to pay for the bytes in the transaction. 4. Transfer the transaction value from the sender's account to the receiving account. If the receiving account does not yet exist, create it. If the receiving account is a contract, run the contract's code either to completion or until the execution runs out of gas. @@ -247,7 +247,7 @@ The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, altho 7. Let `S_FINAL` be `S[n]`, but adding the block reward paid to the miner. 8. Check if the Merkle tree root of the state `S_FINAL` is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid. -The approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin. The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed. Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (ie. hashes of subtrees). A special kind of tree known as a "Patricia tree" is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently. Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history - a strategy which, if it could be applied to Bitcoin, can be calculated to provide 5-20x savings in space. +The approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin. The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed. Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (i.e., hashes of subtrees). A special kind of tree known as a "Patricia tree" is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently. Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history - a strategy which, if it could be applied to Bitcoin, can be calculated to provide 5-20x savings in space. A commonly asked question is "where" contract code is executed, in terms of physical hardware. This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block `B` the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block `B`. @@ -272,7 +272,7 @@ This is essentially a literal implementation of the "banking system" state trans ### Financial derivatives and Stable-Value Currencies {#financial-derivatives-and-stable-value-currencies} -Financial derivatives are the most common application of a "smart contract", and one of the simplest to implement in code. The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar, but doing this requires the contract to know what the value of ETH/USD is. The simplest way to do this is through a "data feed" contract maintained by a specific party (eg. NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price. +Financial derivatives are the most common application of a "smart contract", and one of the simplest to implement in code. The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar, but doing this requires the contract to know what the value of ETH/USD is. The simplest way to do this is through a "data feed" contract maintained by a specific party (e.g., NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price. Given that critical ingredient, the hedging contract would look as follows: @@ -281,9 +281,9 @@ Given that critical ingredient, the hedging contract would look as follows: 3. Record the USD value of 1000 ether, calculated by querying the data feed contract, in storage, say this is $x. 4. After 30 days, allow A or B to "reactivate" the contract in order to send $x worth of ether (calculated by querying the data feed contract again to get the new price) to A and the rest to B. -Such a contract would have significant potential in crypto-commerce. One of the main problems cited about cryptocurrency is the fact that it's volatile; although many users and merchants may want the security and convenience of dealing with cryptographic assets, they many not wish to face that prospect of losing 23% of the value of their funds in a single day. Up until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a sub-currency in which they have the right to issue and revoke units, and provide one unit of the currency to anyone who provides them (offline) with one unit of a specified underlying asset (eg. gold, USD). The issuer then promises to provide one unit of the underlying asset to anyone who sends back one unit of the crypto-asset. This mechanism allows any non-cryptographic asset to be "uplifted" into a cryptographic asset, provided that the issuer can be trusted. +Such a contract would have significant potential in crypto-commerce. One of the main problems cited about cryptocurrency is the fact that it's volatile; although many users and merchants may want the security and convenience of dealing with cryptographic assets, they many not wish to face that prospect of losing 23% of the value of their funds in a single day. Up until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a sub-currency in which they have the right to issue and revoke units, and provide one unit of the currency to anyone who provides them (offline) with one unit of a specified underlying asset (e.g., gold, USD). The issuer then promises to provide one unit of the underlying asset to anyone who sends back one unit of the crypto-asset. This mechanism allows any non-cryptographic asset to be "uplifted" into a cryptographic asset, provided that the issuer can be trusted. -In practice, however, issuers are not always trustworthy, and in some cases the banking infrastructure is too weak, or too hostile, for such services to exist. Financial derivatives provide an alternative. Here, instead of a single issuer providing the funds to back up an asset, a decentralized market of speculators, betting that the price of a cryptographic reference asset (eg. ETH) will go up, plays that role. Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow. Note that this approach is not fully decentralized, because a trusted source is still needed to provide the price ticker, although arguably even still this is a massive improvement in terms of reducing infrastructure requirements (unlike being an issuer, issuing a price feed requires no licenses and can likely be categorized as free speech) and reducing the potential for fraud. +In practice, however, issuers are not always trustworthy, and in some cases the banking infrastructure is too weak, or too hostile, for such services to exist. Financial derivatives provide an alternative. Here, instead of a single issuer providing the funds to back up an asset, a decentralized market of speculators, betting that the price of a cryptographic reference asset (e.g., ETH) will go up, plays that role. Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow. Note that this approach is not fully decentralized, because a trusted source is still needed to provide the price ticker, although arguably even still this is a massive improvement in terms of reducing infrastructure requirements (unlike being an issuer, issuing a price feed requires no licenses and can likely be categorized as free speech) and reducing the potential for fraud. ### Identity and Reputation Systems {#identity-and-reputation-systems} @@ -295,13 +295,13 @@ def register(name, value): self.storage[name] = value ``` -The contract is very simple; all it is a database inside the Ethereum network that can be added to, but not modified or removed from. Anyone can register a name with some value, and that registration then sticks forever. A more sophisticated name registration contract will also have a "function clause" allowing other contracts to query it, as well as a mechanism for the "owner" (ie. the first registerer) of a name to change the data or transfer ownership. One can even add reputation and web-of-trust functionality on top. +The contract is very simple; all it is a database inside the Ethereum network that can be added to, but not modified or removed from. Anyone can register a name with some value, and that registration then sticks forever. A more sophisticated name registration contract will also have a "function clause" allowing other contracts to query it, as well as a mechanism for the "owner" (i.e., the first registerer) of a name to change the data or transfer ownership. One can even add reputation and web-of-trust functionality on top. ### Decentralized File Storage {#decentralized-file-storage} Over the past few years, there have emerged a number of popular online file storage startups, the most prominent being Dropbox, seeking to allow users to upload a backup of their hard drive and have the service store the backup and allow the user to access it in exchange for a monthly fee. However, at this point the file storage market is at times relatively inefficient; a cursory look at various existing solutions shows that, particularly at the "uncanny valley" 20-200 GB level at which neither free quotas nor enterprise-level discounts kick in, monthly prices for mainstream file storage costs are such that you are paying for more than the cost of the entire hard drive in a single month. Ethereum contracts can allow for the development of a decentralized file storage ecosystem, where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage. -The key underpinning piece of such a device would be what we have termed the "decentralized Dropbox contract". This contract works as follows. First, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it. One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree. When a user wants to re-download their file, they can use a micropayment channel protocol (eg. pay 1 szabo per 32 kilobytes) to recover the file; the most fee-efficient approach is for the payer not to publish the transaction until the end, instead replacing the transaction with a slightly more lucrative one with the same nonce after every 32 kilobytes. +The key underpinning piece of such a device would be what we have termed the "decentralized Dropbox contract". This contract works as follows. First, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it. One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree. When a user wants to re-download their file, they can use a micropayment channel protocol (e.g., pay 1 szabo per 32 kilobytes) to recover the file; the most fee-efficient approach is for the payer not to publish the transaction until the end, instead replacing the transaction with a slightly more lucrative one with the same nonce after every 32 kilobytes. An important feature of the protocol is that, although it may seem like one is trusting many random nodes not to decide to forget the file, one can reduce that risk down to near-zero by splitting the file into many pieces via secret sharing, and watching the contracts to see each piece is still in some node's possession. If a contract is still paying out money, that provides a cryptographic proof that someone out there is still storing the file. @@ -315,7 +315,7 @@ A general outline for how to code a DAO is as follows. The simplest design is si - `[1,i]` to register a vote in favor of proposal `i` - `[2,i]` to finalize proposal `i` if enough votes have been made -The contract would then have clauses for each of these. It would maintain a record of all open storage changes, along with a list of who voted for them. It would also have a list of all members. When any storage change gets to two thirds of members voting for it, a finalizing transaction could execute the change. A more sophisticated skeleton would also have built-in voting ability for features like sending a transaction, adding members and removing members, and may even provide for [Liquid Democracy](https://wikipedia.org/wiki/Liquid_democracy)-style vote delegation (ie. anyone can assign someone to vote for them, and assignment is transitive so if A assigns B and B assigns C then C determines A's vote). This design would allow the DAO to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering out who is a member to specialists, although unlike in the "current system" specialists can easily pop in and out of existence over time as individual community members change their alignments. +The contract would then have clauses for each of these. It would maintain a record of all open storage changes, along with a list of who voted for them. It would also have a list of all members. When any storage change gets to two thirds of members voting for it, a finalizing transaction could execute the change. A more sophisticated skeleton would also have built-in voting ability for features like sending a transaction, adding members and removing members, and may even provide for [Liquid Democracy](https://wikipedia.org/wiki/Liquid_democracy)-style vote delegation (i.e., anyone can assign someone to vote for them, and assignment is transitive so if A assigns B and B assigns C then C determines A's vote). This design would allow the DAO to grow organically as a decentralized community, allowing people to eventually delegate the task of filtering out who is a member to specialists, although unlike in the "current system" specialists can easily pop in and out of existence over time as individual community members change their alignments. An alternative model is for a decentralized corporation, where any account can have zero or more shares, and two thirds of the shares are required to make a decision. A complete skeleton would involve asset management functionality, the ability to make an offer to buy or sell shares, and the ability to accept offers (preferably with an order-matching mechanism inside the contract). Delegation would also exist Liquid Democracy-style, generalizing the concept of a "board of directors". @@ -331,11 +331,11 @@ Normally, 1% per day is enough for Alice, and if Alice wants to withdraw more sh **2. Crop insurance**. One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index. If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well. This can be expanded to natural disaster insurance generally. -**3. A decentralized data feed**. For financial contracts for difference, it may actually be possible to decentralize the data feed via a protocol called "[SchellingCoin](http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/)". SchellingCoin basically works as follows: N parties all put into the system the value of a given datum (eg. the ETH/USD price), the values are sorted, and everyone between the 25th and 75th percentile gets one token as a reward. Everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: the truth. This creates a decentralized protocol that can theoretically provide any number of values, including the ETH/USD price, the temperature in Berlin or even the result of a particular hard computation. +**3. A decentralized data feed**. For financial contracts for difference, it may actually be possible to decentralize the data feed via a protocol called "[SchellingCoin](http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/)". SchellingCoin basically works as follows: N parties all put into the system the value of a given datum (e.g., the ETH/USD price), the values are sorted, and everyone between the 25th and 75th percentile gets one token as a reward. Everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: the truth. This creates a decentralized protocol that can theoretically provide any number of values, including the ETH/USD price, the temperature in Berlin or even the result of a particular hard computation. **4. Smart multisignature escrow**. Bitcoin allows multisignature transaction contracts where, for example, three out of a given five keys can spend the funds. Ethereum allows for more granularity; for example, four out of five can spend everything, three out of five can spend up to 10% per day, and two out of five can spend up to 0.5% per day. Additionally, Ethereum multisig is asynchronous - two parties can register their signatures on the blockchain at different times and the last signature will automatically send the transaction. -**5. Cloud computing**. The EVM technology can also be used to create a verifiable computing environment, allowing users to ask others to carry out computations and then optionally ask for proofs that computations at certain randomly selected checkpoints were done correctly. This allows for the creation of a cloud computing market where any user can participate with their desktop, laptop or specialized server, and spot-checking together with security deposits can be used to ensure that the system is trustworthy (ie. nodes cannot profitably cheat). Although such a system may not be suitable for all tasks; tasks that require a high level of inter-process communication, for example, cannot easily be done on a large cloud of nodes. Other tasks, however, are much easier to parallelize; projects like SETI@home, folding@home and genetic algorithms can easily be implemented on top of such a platform. +**5. Cloud computing**. The EVM technology can also be used to create a verifiable computing environment, allowing users to ask others to carry out computations and then optionally ask for proofs that computations at certain randomly selected checkpoints were done correctly. This allows for the creation of a cloud computing market where any user can participate with their desktop, laptop or specialized server, and spot-checking together with security deposits can be used to ensure that the system is trustworthy (i.e., nodes cannot profitably cheat). Although such a system may not be suitable for all tasks; tasks that require a high level of inter-process communication, for example, cannot easily be done on a large cloud of nodes. Other tasks, however, are much easier to parallelize; projects like SETI@home, folding@home and genetic algorithms can easily be implemented on top of such a platform. **6. Peer-to-peer gambling**. Any number of peer-to-peer gambling protocols, such as Frank Stajano and Richard Clayton's [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf), can be implemented on the Ethereum blockchain. The simplest gambling protocol is actually simply a contract for difference on the next block hash, and more advanced protocols can be built up from there, creating gambling services with near-zero fees that have no ability to cheat. @@ -370,8 +370,8 @@ Because every transaction published into the blockchain imposes on the network t However, as it turns out this flaw in the market-based mechanism, when given a particular inaccurate simplifying assumption, magically cancels itself out. The argument is as follows. Suppose that: 1. A transaction leads to `k` operations, offering the reward `kR` to any miner that includes it where `R` is set by the sender and `k` and `R` are (roughly) visible to the miner beforehand. -2. An operation has a processing cost of `C` to any node (ie. all nodes have equal efficiency) -3. There are `N` mining nodes, each with exactly equal processing power (ie. `1/N` of total) +2. An operation has a processing cost of `C` to any node (i.e., all nodes have equal efficiency) +3. There are `N` mining nodes, each with exactly equal processing power (i.e., `1/N` of total) 4. No non-mining full nodes exist. A miner would be willing to process a transaction if the expected reward is greater than the cost. Thus, the expected reward is `kR/N` since the miner has a `1/N` chance of processing the next block, and the processing cost for the miner is simply `kC`. Hence, miners will include transactions where `kR/N > kC`, or `R > NC`. Note that `R` is the per-operation fee provided by the sender, and is thus a lower bound on the benefit that the sender derives from the transaction, and `NC` is the cost to the entire network together of processing an operation. Hence, miners have the incentive to include only those transactions for which the total utilitarian benefit exceeds the cost. @@ -409,7 +409,7 @@ As described in the state transition section, our solution works by requiring a - An attacker creates a contract which runs an infinite loop, and then sends a transaction activating that loop to the miner. The miner will process the transaction, running the infinite loop, and wait for it to run out of gas. Even though the execution runs out of gas and stops halfway through, the transaction is still valid and the miner still claims the fee from the attacker for each computational step. - An attacker creates a very long infinite loop with the intent of forcing the miner to keep computing for such a long time that by the time computation finishes a few more blocks will have come out and it will not be possible for the miner to include the transaction to claim the fee. However, the attacker will be required to submit a value for `STARTGAS` limiting the number of computational steps that execution can take, so the miner will know ahead of time that the computation will take an excessively large number of steps. -- An attacker sees a contract with code of some form like `send(A,contract.storage[A]); contract.storage[A] = 0`, and sends a transaction with just enough gas to run the first step but not the second (ie. making a withdrawal but not letting the balance go down). The contract author does not need to worry about protecting against such attacks, because if execution stops halfway through the changes get reverted. +- An attacker sees a contract with code of some form like `send(A,contract.storage[A]); contract.storage[A] = 0`, and sends a transaction with just enough gas to run the first step but not the second (i.e., making a withdrawal but not letting the balance go down). The contract author does not need to worry about protecting against such attacks, because if execution stops halfway through the changes get reverted. - A financial contract works by taking the median of nine proprietary data feeds in order to minimize risk. An attacker takes over one of the data feeds, which is designed to be modifiable via the variable-address-call mechanism described in the section on DAOs, and converts it to run an infinite loop, thereby attempting to force any attempts to claim funds from the financial contract to run out of gas. However, the financial contract can set a gas limit on the message to prevent this problem. The alternative to Turing-completeness is Turing-incompleteness, where `JUMP` and `JUMPI` do not exist and only one copy of each contract is allowed to exist in the call stack at any given time. With this system, the fee system described and the uncertainties around the effectiveness of our solution might not be necessary, as the cost of executing a contract would be bounded above by its size. Additionally, Turing-incompleteness is not even that big a limitation; out of all the contract examples we have conceived internally, so far only one required a loop, and even that loop could be removed by making 26 repetitions of a one-line piece of code. Given the serious implications of Turing-completeness, and the limited benefit, why not simply have a Turing-incomplete language? In reality, however, Turing-incompleteness is far from a neat solution to the problem. To see why, consider the following contracts: @@ -459,7 +459,7 @@ _Despite the linear currency issuance, just like with Bitcoin over time the supp The two main choices in the above model are (1) the existence and size of an endowment pool, and (2) the existence of a permanently growing linear supply, as opposed to a capped supply as in Bitcoin. The justification of the endowment pool is as follows. If the endowment pool did not exist, and the linear issuance reduced to 0.217x to provide the same inflation rate, then the total quantity of ether would be 16.5% less and so each unit would be 19.8% more valuable. Hence, in the equilibrium 19.8% more ether would be purchased in the sale, so each unit would once again be exactly as valuable as before. The organization would also then have 1.198x as much BTC, which can be considered to be split into two slices: the original BTC, and the additional 0.198x. Hence, this situation is _exactly equivalent_ to the endowment, but with one important difference: the organization holds purely BTC, and so is not incentivized to support the value of the ether unit. -The permanent linear supply growth model reduces the risk of what some see as excessive wealth concentration in Bitcoin, and gives individuals living in present and future eras a fair chance to acquire currency units, while at the same time retaining a strong incentive to obtain and hold ether because the "supply growth rate" as a percentage still tends to zero over time. We also theorize that because coins are always lost over time due to carelessness, death, etc, and coin loss can be modeled as a percentage of the total supply per year, that the total currency supply in circulation will in fact eventually stabilize at a value equal to the annual issuance divided by the loss rate (eg. at a loss rate of 1%, once the supply reaches 26X then 0.26X will be mined and 0.26X lost every year, creating an equilibrium). +The permanent linear supply growth model reduces the risk of what some see as excessive wealth concentration in Bitcoin, and gives individuals living in present and future eras a fair chance to acquire currency units, while at the same time retaining a strong incentive to obtain and hold ether because the "supply growth rate" as a percentage still tends to zero over time. We also theorize that because coins are always lost over time due to carelessness, death, etc, and coin loss can be modeled as a percentage of the total supply per year, that the total currency supply in circulation will in fact eventually stabilize at a value equal to the annual issuance divided by the loss rate (e.g., at a loss rate of 1%, once the supply reaches 26X then 0.26X will be mined and 0.26X lost every year, creating an equilibrium). Note that in the future, it is likely that Ethereum will switch to a proof-of-stake model for security, reducing the issuance requirement to somewhere between zero and 0.05X per year. In the event that the Ethereum organization loses funding or for any other reason disappears, we leave open a "social contract": anyone has the right to create a future candidate version of Ethereum, with the only condition being that the quantity of ether must be at most equal to `60102216 * (1.198 + 0.26 * n)` where `n` is the number of years after the genesis block. Creators are free to crowd-sell or otherwise assign some or all of the difference between the PoS-driven supply expansion and the maximum allowable supply expansion to pay for development. Candidate upgrades that do not comply with the social contract may justifiably be forked into compliant versions. @@ -467,7 +467,7 @@ Note that in the future, it is likely that Ethereum will switch to a proof-of-st The Bitcoin mining algorithm works by having miners compute SHA256 on slightly modified versions of the block header millions of times over and over again, until eventually one node comes up with a version whose hash is less than the target (currently around 2192). However, this mining algorithm is vulnerable to two forms of centralization. First, the mining ecosystem has come to be dominated by ASICs (application-specific integrated circuits), computer chips designed for, and therefore thousands of times more efficient at, the specific task of Bitcoin mining. This means that Bitcoin mining is no longer a highly decentralized and egalitarian pursuit, requiring millions of dollars of capital to effectively participate in. Second, most Bitcoin miners do not actually perform block validation locally; instead, they rely on a centralized mining pool to provide the block headers. This problem is arguably worse: as of the time of this writing, the top three mining pools indirectly control roughly 50% of processing power in the Bitcoin network, although this is mitigated by the fact that miners can switch to other mining pools if a pool or coalition attempts a 51% attack. -The current intent at Ethereum is to use a mining algorithm where miners are required to fetch random data from the state, compute some randomly selected transactions from the last N blocks in the blockchain, and return the hash of the result. This has two important benefits. First, Ethereum contracts can include any kind of computation, so an Ethereum ASIC would essentially be an ASIC for general computation - ie. a better CPU. Second, mining requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be capable of verifying every transaction. This removes the need for centralized mining pools; although mining pools can still serve the legitimate role of evening out the randomness of reward distribution, this function can be served equally well by peer-to-peer pools with no central control. +The current intent at Ethereum is to use a mining algorithm where miners are required to fetch random data from the state, compute some randomly selected transactions from the last N blocks in the blockchain, and return the hash of the result. This has two important benefits. First, Ethereum contracts can include any kind of computation, so an Ethereum ASIC would essentially be an ASIC for general computation - i.e., a better CPU. Second, mining requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be capable of verifying every transaction. This removes the need for centralized mining pools; although mining pools can still serve the legitimate role of evening out the randomness of reward distribution, this function can be served equally well by peer-to-peer pools with no central control. This model is untested, and there may be difficulties along the way in avoiding certain clever optimizations when using contract execution as a mining algorithm. However, one notably interesting feature of this algorithm is that it allows anyone to "poison the well", by introducing a large number of contracts into the blockchain specifically designed to stymie certain ASICs. The economic incentives exist for ASIC manufacturers to use such a trick to attack each other. Thus, the solution that we are developing is ultimately an adaptive economic human solution rather than purely a technical one. @@ -475,7 +475,7 @@ This model is untested, and there may be difficulties along the way in avoiding One common concern about Ethereum is the issue of scalability. Like Bitcoin, Ethereum suffers from the flaw that every transaction needs to be processed by every node in the network. With Bitcoin, the size of the current blockchain rests at about 15 GB, growing by about 1 MB per hour. If the Bitcoin network were to process Visa's 2000 transactions per second, it would grow by 1 MB per three seconds (1 GB per hour, 8 TB per year). Ethereum is likely to suffer a similar growth pattern, worsened by the fact that there will be many applications on top of the Ethereum blockchain instead of just a currency as is the case with Bitcoin, but ameliorated by the fact that Ethereum full nodes need to store just the state instead of the entire blockchain history. -The problem with such a large blockchain size is centralization risk. If the blockchain size increases to, say, 100 TB, then the likely scenario would be that only a very small number of large businesses would run full nodes, with all regular users using light SPV nodes. In such a situation, there arises the potential concern that the full nodes could band together and all agree to cheat in some profitable fashion (eg. change the block reward, give themselves BTC). Light nodes would have no way of detecting this immediately. Of course, at least one honest full node would likely exist, and after a few hours information about the fraud would trickle out through channels like Reddit, but at that point it would be too late: it would be up to the ordinary users to organize an effort to blacklist the given blocks, a massive and likely infeasible coordination problem on a similar scale as that of pulling off a successful 51% attack. In the case of Bitcoin, this is currently a problem, but there exists a blockchain modification [suggested by Peter Todd](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) which will alleviate this issue. +The problem with such a large blockchain size is centralization risk. If the blockchain size increases to, say, 100 TB, then the likely scenario would be that only a very small number of large businesses would run full nodes, with all regular users using light SPV nodes. In such a situation, there arises the potential concern that the full nodes could band together and all agree to cheat in some profitable fashion (e.g., change the block reward, give themselves BTC). Light nodes would have no way of detecting this immediately. Of course, at least one honest full node would likely exist, and after a few hours information about the fraud would trickle out through channels like Reddit, but at that point it would be too late: it would be up to the ordinary users to organize an effort to blacklist the given blocks, a massive and likely infeasible coordination problem on a similar scale as that of pulling off a successful 51% attack. In the case of Bitcoin, this is currently a problem, but there exists a blockchain modification [suggested by Peter Todd](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) which will alleviate this issue. In the near term, Ethereum will use two additional strategies to cope with this problem. First, because of the blockchain-based mining algorithms, at least every miner will be forced to be a full node, creating a lower bound on the number of full nodes. Second and more importantly, however, we will include an intermediate state tree root in the blockchain after processing each transaction. Even if block validation is centralized, as long as one honest verifying node exists, the centralization problem can be circumvented via a verification protocol. If a miner publishes an invalid block, that block must either be badly formatted, or the state `S[n]` is incorrect. Since `S[0]` is known to be correct, there must be some first state `S[i]` that is incorrect where `S[i-1]` is correct. The verifying node would provide the index `i`, along with a "proof of invalidity" consisting of the subset of Patricia tree nodes needing to process `APPLY(S[i-1],TX[i]) -> S[i]`. Nodes would be able to use those nodes to run that part of the computation, and see that the `S[i]` generated does not match the `S[i]` provided. From 3e7c9121eeeea825d4c8c4af8405a64282ca23db Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:32:53 -0500 Subject: [PATCH 206/212] hard stops on learn-quizzes --- src/intl/en/learn-quizzes.json | 2 +- src/intl/ga/learn-quizzes.json | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/intl/en/learn-quizzes.json b/src/intl/en/learn-quizzes.json index ca022b1281d..abbbb02fb9d 100644 --- a/src/intl/en/learn-quizzes.json +++ b/src/intl/en/learn-quizzes.json @@ -429,7 +429,7 @@ "staking-solo-2-a-label": "No affect on rewards", "staking-solo-2-a-explanation": "Penalties are incurred when a validator is unavailable to attest to the state of the chain for any given epoch. The size of these penalties is approximately equal to 75% of what the reward for a proper attestation would have been. Rewards resume when validator goes back online, and NO slashing occurs.", "staking-solo-2-b-label": "Inactivity penalties are incurred only while unavailable", - "staking-solo-2-b-explanation": "While unavailable, a validator will incur small inactivity penalties, approximately equal to 75% of what the reward would have been for a proper attestation. In rare/extreme cases where the network is not finalizing (i.e. over 1/3 of the network is also offline), these penalties are significantly greater. Rewards resume when validator goes back online, and no slashing occurs.", + "staking-solo-2-b-explanation": "While unavailable, a validator will incur small inactivity penalties, approximately equal to 75% of what the reward would have been for a proper attestation. In rare/extreme cases where the network is not finalizing (i.e., over 1/3 of the network is also offline), these penalties are significantly greater. Rewards resume when validator goes back online, and no slashing occurs.", "staking-solo-2-c-label": "Immediate slashing and removal from the network", "staking-solo-2-c-explanation": "This is a common misconception, but going offline does NOT result in slashing! Slashing is a specific type of penalty for more serious offense, with larger penalties and also results in removal from the validator set.", "staking-solo-2-d-label": "One week delay before slashing and ejection", diff --git a/src/intl/ga/learn-quizzes.json b/src/intl/ga/learn-quizzes.json index 9f32d732b41..7e08773968c 100644 --- a/src/intl/ga/learn-quizzes.json +++ b/src/intl/ga/learn-quizzes.json @@ -384,7 +384,7 @@ "staking-solo-2-a-label": "Gan aon tionchar ar luaíochtaí", "staking-solo-2-a-explanation": "Tabhaítear pionóis nuair nach mbíonn bailíochtóir ar fáil chun staid an tslabhra a fhianú d’aon ré ar leith. Is ionann méid na bpionós seo agus 75% den luach a bheadh ​​ar fhianú ceart. Atosóidh luach saothair nuair a théann an bailíochtóir ar ais ar líne, agus NÍL aon slaiseadh.", "staking-solo-2-b-label": "Ní thabhaítear pionóis neamhghníomhaíochta ach amháin nuair nach mbíonn siad ar fáil", - "staking-solo-2-b-explanation": "Cé nach bhfuil sé ar fáil, tabhóidh bailíochtóir pionóis bheaga neamhghníomhaíochta, arb ionann iad agus 75% den luach a bheadh ​​ar fhianú ceart. I gcásanna neamhchoitianta/fíorchúiseacha nach bhfuil an líonra á thabhairt chun críche (i.e. tá níos mó ná 1/3 den líonra as líne freisin), bíonn na pionóis seo i bhfad níos airde. Atosóidh luach saothair nuair a théann bailíochtóir ar ais ar líne, agus ní tharlaíonn aon slais.", + "staking-solo-2-b-explanation": "Cé nach bhfuil sé ar fáil, tabhóidh bailíochtóir pionóis bheaga neamhghníomhaíochta, arb ionann iad agus 75% den luach a bheadh ​​ar fhianú ceart. I gcásanna neamhchoitianta/fíorchúiseacha nach bhfuil an líonra á thabhairt chun críche (i.e., tá níos mó ná 1/3 den líonra as líne freisin), bíonn na pionóis seo i bhfad níos airde. Atosóidh luach saothair nuair a théann bailíochtóir ar ais ar líne, agus ní tharlaíonn aon slais.", "staking-solo-2-c-label": "Slaiseáil láithreach agus a bhaint as an líonra", "staking-solo-2-c-explanation": "Is míthuiscint choitianta é seo, ach NÍL slaiseáil mar thoradh ar dhul as líne! Is cineál sonrach pionóis é slaiseáil i leith cion níos tromchúisí, le pionóis níos mó agus baintear as an tacar bailíochtaithe é freisin.", "staking-solo-2-d-label": "Moille seachtaine amháin roimh slaiseáil agus díshealbhú", From 3407d8106aa3bc21cba776dd00337fb1ef6cd50e Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:33:19 -0500 Subject: [PATCH 207/212] hard stops on page-taking.json --- src/intl/en/page-staking.json | 2 +- src/intl/ga/page-staking.json | 2 +- src/intl/pcm/page-staking.json | 2 +- src/intl/yo/page-staking.json | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/intl/en/page-staking.json b/src/intl/en/page-staking.json index 6854bbfe4f1..b16f22ccbc6 100644 --- a/src/intl/en/page-staking.json +++ b/src/intl/en/page-staking.json @@ -205,7 +205,7 @@ "page-staking-faq-2-answer": "A validator has the ability to propose and attest to blocks for the network. To prevent dishonest behavior, users must have their funds at stake. This allows the protocol to penalize malicious actors. Staking is a means to keep you honest, as your actions will have financial consequences.", "page-staking-faq-3-question": "Can I buy 'Eth2'?", "page-staking-faq-3-answer-p1": "There is no 'Eth2' token native to the protocol, as the native token ether (ETH) did not change when Ethereum switched to proof-of-stake.", - "page-staking-faq-3-answer-p2": "There are derivative tokens/tickers that may represent staked ETH (ie. rETH from Rocket Pool, stETH from Lido, ETH2 from Coinbase). Learn more about staking pools", + "page-staking-faq-3-answer-p2": "There are derivative tokens/tickers that may represent staked ETH (i.e., rETH from Rocket Pool, stETH from Lido, ETH2 from Coinbase). Learn more about staking pools", "page-staking-faq-4-question": "Is staking already live?", "page-staking-faq-4-answer-p1": "Yes. Staking has been live since December 1, 2020", "page-staking-faq-4-answer-p2": "This means that staking is currently live for users to deposit their ETH, run a validator client, and start earning rewards.", diff --git a/src/intl/ga/page-staking.json b/src/intl/ga/page-staking.json index 0b7ad569d54..203fcc44b64 100644 --- a/src/intl/ga/page-staking.json +++ b/src/intl/ga/page-staking.json @@ -205,7 +205,7 @@ "page-staking-faq-2-answer": "Tá an cumas ag bailíochtóir bloic don líonra a mholadh agus a fhianú. Chun iompar mímhacánta a chosc, caithfidh úsáideoirí a gcuid cistí a bheith i gceist leis an ngeallchur. Leis sin ligtear don phrótacal pionós a ghearradh ar ghníomhuithe mailíseacha. Is bealach é an geallchur chun thú a choinneáil macánta, mar beidh iarmhairtí airgeadais ag do ghníomhartha.", "page-staking-faq-3-question": "An féidir liom 'Eth2' a cheannach?", "page-staking-faq-3-answer-p1": "Níl aon chomhartha 'Eth2' ann atá dúchasach don phrótacal, mar níor athraíodh comhartha dúchais an éitir (ETH) nuair a bogadh Ethereum go cruthúnas geallchuir.", - "page-staking-faq-3-answer-p2": "Tá comharthaí/ticeoirí díorthacha ann a d'fhéadfadh a bheith mar ETH geallchurtha (ie. rETH ó Rocket Pool, stETH ó Lido, ETH2 ó Coinbase). Foghlaim tuilleadh faoi linnte geallchuir", + "page-staking-faq-3-answer-p2": "Tá comharthaí/ticeoirí díorthacha ann a d'fhéadfadh a bheith mar ETH geallchurtha (i.e., rETH ó Rocket Pool, stETH ó Lido, ETH2 ó Coinbase). Foghlaim tuilleadh faoi linnte geallchuir", "page-staking-faq-4-question": "An bhfuiltear i mbun geallchuir cheana féin?", "page-staking-faq-4-answer-p1": "Tá. Tá an Geallchur beo ón 1 Nollaig 2020", "page-staking-faq-4-answer-p2": "Ciallaíonn sé seo go bhfuil an geallchur beo faoi láthair le haghaidh úsáideoirí chun a gcuid ETH a íoc mar éarlais, chun cliant bailíochtaithe a rith agus chun tús a chur le luaíochtaí a thuilleamh.", diff --git a/src/intl/pcm/page-staking.json b/src/intl/pcm/page-staking.json index 59f62cac049..16e299e887d 100644 --- a/src/intl/pcm/page-staking.json +++ b/src/intl/pcm/page-staking.json @@ -204,7 +204,7 @@ "page-staking-faq-2-answer": "Pesin wey dey validate get pawa to propose and attest to blocks for di netwok. To privent dishonest bihavior, users suppose get dem funds at stake. Dis dey allow di protokol to penalize malisjios aktors. Staking na means to make dey honest, as yor akshons go get finashia konsikwensis.", "page-staking-faq-3-question": "I fit buy 'Eth2'?", "page-staking-faq-3-answer-p1": "'Eth2' token native to di protokol nor dey, as di native token ether (ETH) nor shanj wen Ethereum don switch for proof-of-stake.", - "page-staking-faq-3-answer-p2": "Dem derivative tokens/tickers wey fit reprisent staked ETH (ie. rETH from Rocket Pool, stETH from Lido, ETH2 from Coinbase). Learn more abou staking pools", + "page-staking-faq-3-answer-p2": "Dem derivative tokens/tickers wey fit reprisent staked ETH (i.e., rETH from Rocket Pool, stETH from Lido, ETH2 from Coinbase). Learn more abou staking pools", "page-staking-faq-4-question": "Staking don dey live already?", "page-staking-faq-4-answer-p1": "Na so. Staking don dey live sinse December 1, 2020", "page-staking-faq-4-answer-p2": "Dis mean sey staking dey live nau for users to deposit dem ETH, run one validator klient, kon start to dey earn riwods.", diff --git a/src/intl/yo/page-staking.json b/src/intl/yo/page-staking.json index 9487771ad86..35f062ac346 100644 --- a/src/intl/yo/page-staking.json +++ b/src/intl/yo/page-staking.json @@ -186,7 +186,7 @@ "page-staking-faq-2-answer": "Olùṣàyẹ̀wò ní agbára láti gbèrò àti jẹ́rìí sí búlọ́ọ́kù fún nẹ́tíwọọkì náà. Láti dènà ìwà àìṣòdodo, àṣàmúlo gbọ́dọ̀ ní owó ní ìdókòwò. Èyí yóò jẹ́ kí ìlànà fi ìyà jẹ aláìṣedéédé. Dídókòwò jẹ́ ọ̀nà láti jẹ́ olóòtọ, nítorí pé iṣẹ́ rẹ yóò ní àbájáde.", "page-staking-faq-3-question": "Ṣé mo lè ra 'Eth2'?", "page-staking-faq-3-answer-p1": "Kò sí tọ́kẹ̀n 'ETH2' tó jẹ́ abínibí sí ìlànà náà, tọ́kẹ̀n abínibí ether(ETH) kò yí padà nígbàtí Ethereum yí padà sí ìjẹ́rìí sí ìdókòwò.", - "page-staking-faq-3-answer-p2": "Àwọn tọ́kẹ̀n/tíkásì ìtọ̀sẹ̀ tó lè sójú ETH tí a fi dókòwò(ie. rETH láti Rocket Pool, stETH láti Lido, ETH2 láti Coinbase). kọ́ síi nípa ìdókòwò alápapọ̀", + "page-staking-faq-3-answer-p2": "Àwọn tọ́kẹ̀n/tíkásì ìtọ̀sẹ̀ tó lè sójú ETH tí a fi dókòwò(i.e., rETH láti Rocket Pool, stETH láti Lido, ETH2 láti Coinbase). kọ́ síi nípa ìdókòwò alápapọ̀", "page-staking-faq-4-question": "Ǹjẹ́ ìdókòwò ti wà láàyè lórí ayélujára?", "page-staking-faq-4-answer-p1": "Bẹ́ẹ̀nì. Ìdókòwò ti wà láàyè láti oṣù kejìlá, odún 2020", "page-staking-faq-4-answer-p2": "Èyí túnmọ̀ sí pé ìdókòwò wà lọ́wọ́lọ́wọ́ fún àwọn aṣàmúlò láti fi ETH wọn pamọ́, mú oníbàárà olùṣàyẹ̀wò ṣiṣẹ́, àti bèrè sí ní jẹ èrè.", From ee7055710e0968905c5fd592c3db6f4f7905e96f Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:33:32 -0500 Subject: [PATCH 208/212] hard stops on glossary.json --- src/intl/en/glossary.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/intl/en/glossary.json b/src/intl/en/glossary.json index 71037454e60..3f201f3d294 100644 --- a/src/intl/en/glossary.json +++ b/src/intl/en/glossary.json @@ -134,7 +134,7 @@ "erc-1155-term": "ERC-1155", "erc-1155-definition": "ERC-1155 is a newer type of Ethereum token standard similar to NFT (like unique collectible items) that also allows to create interchangeable items (like currency) within a single smart contract.
This makes it easier and more efficient to manage various types of digital assets, especially for applications like video games or digital collections.", "erc-20-term": "ERC-20", - "erc-20-definition": "ERC-20 is the standard that most tokens on Ethereum network use for their creation.
Popular examples are stablecoins like DAI and USDC or exchange tokens like UNI from Uniswap. Akin to any form of alternative moneys that we have in traditional systems… ie. rewards points, credit systems, or even stocks, etc.", + "erc-20-definition": "ERC-20 is the standard that most tokens on Ethereum network use for their creation.
Popular examples are stablecoins like DAI and USDC or exchange tokens like UNI from Uniswap. Akin to any form of alternative moneys that we have in traditional systems… i.e., rewards points, credit systems, or even stocks, etc.", "erc-721-term": "ERC-721", "erc-721-definition": "NFTs (non fungible tokens) are created using a standard set of rules referred to as ERC-721.
NFT tokens can represent ownership of anything unique, like digital art or collectibles, with each token having its own special characteristics and value. Each NFT is unique and easily distinguishable from any other NFT.", "execution-client-term": "Execution client", From 9a6347203b09fed3646664f04ac127866c7b07df Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:34:47 -0500 Subject: [PATCH 209/212] hard stops on suggest_staking_product.yaml --- .github/ISSUE_TEMPLATE/suggest_staking_product.yaml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/ISSUE_TEMPLATE/suggest_staking_product.yaml b/.github/ISSUE_TEMPLATE/suggest_staking_product.yaml index 2cf09f2ba93..a1b619e23fc 100644 --- a/.github/ISSUE_TEMPLATE/suggest_staking_product.yaml +++ b/.github/ISSUE_TEMPLATE/suggest_staking_product.yaml @@ -187,17 +187,17 @@ body: id: staking_product_platform_support attributes: label: What platforms are supported? - description: ie. Linux, macOS, Windows, iOS, Android, etc + description: i.e., Linux, macOS, Windows, iOS, Android, etc - type: input id: staking_product_interface attributes: label: What user interfaces are supported? - description: ie. browser app, desktop app, mobile app, CLI app, etc + description: i.e., browser app, desktop app, mobile app, CLI app, etc - type: textarea id: staking_product_socials attributes: label: Social media links - description: List available social media links. ie. Discord, Twitter, Telegram, Reddit + description: List available social media links. i.e., Discord, Twitter, Telegram, Reddit - type: checkboxes id: staking_product_work_on attributes: From a5cff6f5e40a5836173b6ea6cf322b5b5d83b41a Mon Sep 17 00:00:00 2001 From: Pete Date: Tue, 21 Oct 2025 12:37:32 -0500 Subject: [PATCH 210/212] Adding ie. and eg. style guide to avoid usage --- .../style-guide/content-standardization/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/public/content/contributing/style-guide/content-standardization/index.md b/public/content/contributing/style-guide/content-standardization/index.md index 3ba613e96b5..af956685e28 100644 --- a/public/content/contributing/style-guide/content-standardization/index.md +++ b/public/content/contributing/style-guide/content-standardization/index.md @@ -172,12 +172,12 @@ Use the "D-Mon-YYYY" format for dates. This format eliminates ambiguity between By adhering to these guidelines, we create a unified approach to presenting dates, fostering clarity and comprehension throughout Ethereum documentation. -### Hard stops (i.e., and e.g.,) -When using abbreviations such as i.e., or e.g., it should include the comma after the period. This usage will allow for consistency and presentation. +### Hard stops (i.e., and e.g.,) {#hard-stops} +When using abbreviations such as i.e., or e.g., it should include the comma after the second period. This usage will allow for consistency and presentation across the documentation. **Examples:** -- Preferred: i.e., or e.g., the preferred usage -- Avoid: i.e. or e.g. do not use +- Preferred: i.e., or e.g., +- Avoid: i.e. ie. e.g. or eg. ### Linking to internal pages {#internal-links} From 132e37a098dc73e15d0d1285a30149654672e87f Mon Sep 17 00:00:00 2001 From: Pete Date: Mon, 27 Oct 2025 07:54:06 -0500 Subject: [PATCH 211/212] Adding clarification to examples/restatements --- .../content-standardization/index.md | 20 ++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/public/content/contributing/style-guide/content-standardization/index.md b/public/content/contributing/style-guide/content-standardization/index.md index 115b45c8a4b..b9d8a56f7a5 100644 --- a/public/content/contributing/style-guide/content-standardization/index.md +++ b/public/content/contributing/style-guide/content-standardization/index.md @@ -174,13 +174,6 @@ Use the "D-Mon-YYYY" format for dates. This format eliminates ambiguity between By adhering to these guidelines, we create a unified approach to presenting dates, fostering clarity and comprehension throughout Ethereum documentation. -### Hard stops (i.e., and e.g.,) {#hard-stops} -When using abbreviations such as i.e., or e.g., it should include the comma after the second period. This usage will allow for consistency and presentation across the documentation. - -**Examples:** -- Preferred: i.e., or e.g., -- Avoid: i.e. ie. e.g. or eg. - ### Linking to internal pages {#internal-links} When linking to another page on ethereum.org, use the relative path over the absolute path. Do not hard-code the language path (i.e., `/en/`) in any links, and do not include the `https://ethereum.org` domain. This maintains consistent functionality across different language versions of the site. @@ -363,6 +356,19 @@ He was sure of one thing — he would not give up. The results -- despite initial doubts -- were impressive. ``` +### Examples (e.g.,) and Restatements (i..e,) {#example-restatements} +When using examples (e.g.,) or restatements (i.e.,) it should include the comma after the second period. + +Usage: +i.e., (that is) introduces a word or phrase that restates what has already been stated. +e.g., (for example) is used similarly to "for example" preceding an item or list of items. + +This usage will allow for consistency and presentation across the documentation. + +**Examples:** +- Preferred: i.e., or e.g., +- Avoid: i.e. ie. e.g. or eg. + #### Spacing {#dash-spacing} No spaces should appear before or after any dash—hyphen, en dash, or em dash—in standard usage. From b5c057e2e2e215297f5ce9eb94bbfa360d6426f1 Mon Sep 17 00:00:00 2001 From: Paul Wackerow <54227730+wackerow@users.noreply.github.com> Date: Mon, 27 Oct 2025 12:49:07 -0700 Subject: [PATCH 212/212] patch: typo fix, markdown syntax --- app/[locale]/roadmap/_components/roadmap.tsx | 1 - .../style-guide/content-standardization/index.md | 11 +++++++---- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/app/[locale]/roadmap/_components/roadmap.tsx b/app/[locale]/roadmap/_components/roadmap.tsx index 3e450577d75..736407daaa0 100644 --- a/app/[locale]/roadmap/_components/roadmap.tsx +++ b/app/[locale]/roadmap/_components/roadmap.tsx @@ -256,7 +256,6 @@ const RoadmapPage = () => {
-
diff --git a/public/content/contributing/style-guide/content-standardization/index.md b/public/content/contributing/style-guide/content-standardization/index.md index b9d8a56f7a5..d3c7922bec6 100644 --- a/public/content/contributing/style-guide/content-standardization/index.md +++ b/public/content/contributing/style-guide/content-standardization/index.md @@ -356,16 +356,19 @@ He was sure of one thing — he would not give up. The results -- despite initial doubts -- were impressive. ``` -### Examples (e.g.,) and Restatements (i..e,) {#example-restatements} +### Examples (e.g.,) and restatements (i.e.,) {#examples-restatements} + When using examples (e.g.,) or restatements (i.e.,) it should include the comma after the second period. -Usage: -i.e., (that is) introduces a word or phrase that restates what has already been stated. -e.g., (for example) is used similarly to "for example" preceding an item or list of items. +**Usage:** + +- i.e., (that is) introduces a word or phrase that restates what has already been stated. +- e.g., (for example) is used similarly to "for example" preceding an item or list of items. This usage will allow for consistency and presentation across the documentation. **Examples:** + - Preferred: i.e., or e.g., - Avoid: i.e. ie. e.g. or eg.