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 diff --git a/.github/ISSUE_TEMPLATE/suggest_staking_product.yaml b/.github/ISSUE_TEMPLATE/suggest_staking_product.yaml index b8dd89cb28d..9d41d5d883c 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: diff --git a/.github/ISSUE_TEMPLATE/suggest_wallet.yaml b/.github/ISSUE_TEMPLATE/suggest_wallet.yaml index a96fd28b810..09b81f914fd 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: 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. diff --git a/README.md b/README.md index 18cb5b2e6db..0122e6c1737 100644 --- a/README.md +++ b/README.md @@ -135,7 +135,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=` @@ -158,7 +158,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)? diff --git a/docs/applying-storybook.md b/docs/applying-storybook.md index fc47cbf8867..1f98b0c16ad 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. diff --git a/docs/best-practices.md b/docs/best-practices.md index 420116cc108..c687a4bdca6 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** diff --git a/docs/code-conventions.md b/docs/code-conventions.md index 635086abb00..fc0eaa39ed0 100644 --- a/docs/code-conventions.md +++ b/docs/code-conventions.md @@ -65,7 +65,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 diff --git a/docs/ds-implementation.md b/docs/ds-implementation.md index a1628ec8acb..2b570bcced7 100644 --- a/docs/ds-implementation.md +++ b/docs/ds-implementation.md @@ -38,7 +38,7 @@ If you are implementing: ### 🧩 Base components -*(components that already exist in the [shadcn/ui components list](https://ui.shadcn.com/docs/components), e.g. Button, Input, Alert)* +*(components that already exist in the [shadcn/ui components list](https://ui.shadcn.com/docs/components), e.g., Button, Input, Alert)* * Do **not** create a new component file under `/ComponentA/index.tsx` unless additional or custom logic is required. * Extend or style base components in `src/components/ui`. @@ -47,7 +47,7 @@ If you are implementing: ### 🧱 Custom components -*(components not covered by shadcn/ui, e.g. PageHero)* +*(components not covered by shadcn/ui, e.g., PageHero)* * Use base `ui` components whenever possible. * Keep the structure consistent with the DS and Figma specifications. 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: diff --git a/docs/review-process.md b/docs/review-process.md index c45b4286744..8961e8a1d8e 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. 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 diff --git a/public/content/community/code-of-conduct/index.md b/public/content/community/code-of-conduct/index.md index cb0e071c279..79ea864e9f6 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. diff --git a/public/content/community/events/organizing/index.md b/public/content/community/events/organizing/index.md index 62ab3242616..6563c596668 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} diff --git a/public/content/community/research/index.md b/public/content/community/research/index.md index e6c6b4b24d2..eba53da3207 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} diff --git a/public/content/contributing/adding-layer-2s/index.md b/public/content/contributing/adding-layer-2s/index.md index 4a8b887603a..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/) +- 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** 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?** diff --git a/public/content/contributing/design-principles/index.md b/public/content/contributing/design-principles/index.md index dd3c03f0cec..fa87178adec 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: diff --git a/public/content/contributing/style-guide/content-standardization/index.md b/public/content/contributing/style-guide/content-standardization/index.md index 7c53baa3481..d3c7922bec6 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:** @@ -176,7 +176,7 @@ By adhering to these guidelines, we create a unified approach to presenting date ### 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. +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. ```md @@ -356,6 +356,22 @@ 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.,) {#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. + +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. 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} 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 361b20232e7..b9842308f87 100644 --- a/public/content/contributing/translation-program/how-to-translate/index.md +++ b/public/content/contributing/translation-program/how-to-translate/index.md @@ -74,7 +74,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. 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 (/) diff --git a/public/content/decentralized-identity/index.md b/public/content/decentralized-identity/index.md index 9fad9b953ba..6596f75b5e8 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} diff --git a/public/content/developers/docs/apis/backend/index.md b/public/content/developers/docs/apis/backend/index.md index 5d8afa2ea42..1d17b3f5b47 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} diff --git a/public/content/developers/docs/apis/javascript/index.md b/public/content/developers/docs/apis/javascript/index.md index 9ed9af4a19a..f6baa0c7949 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} diff --git a/public/content/developers/docs/apis/json-rpc/index.md b/public/content/developers/docs/apis/json-rpc/index.md index 40cf96ee585..576b10c6028 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. @@ -1648,8 +1648,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. @@ -1659,7 +1659,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` - variable-length non-indexed log data. (In _solidity_: zero or more 32 Bytes non-indexed log arguments.) - - `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** 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 614b9df2f65..7fab50d7e92 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} 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 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) 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: 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 413a6f400c9..d1b1208feca 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} diff --git a/public/content/developers/docs/consensus-mechanisms/pow/index.md b/public/content/developers/docs/consensus-mechanisms/pow/index.md index 54469f38a3d..d56070c2863 100644 --- a/public/content/developers/docs/consensus-mechanisms/pow/index.md +++ b/public/content/developers/docs/consensus-mechanisms/pow/index.md @@ -21,7 +21,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} 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 423aec55da6..89ba6c6f9aa 100644 --- a/public/content/developers/docs/consensus-mechanisms/pow/mining/index.md +++ b/public/content/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -52,7 +52,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. 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 50796bece3a..ca0caf51ddb 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 @@ -52,7 +52,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. 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 3cdbd2d583c..9c7eb37e16c 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 @@ -25,9 +25,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). diff --git a/public/content/developers/docs/data-availability/index.md b/public/content/developers/docs/data-availability/index.md index 1c7dbbedb34..07109c0b917 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. 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 adba8d17e1a..6403c669d27 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 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; 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. 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. 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. diff --git a/public/content/developers/docs/development-networks/index.md b/public/content/developers/docs/development-networks/index.md index 43f3ad7db01..9c60696a2d9 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 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} diff --git a/public/content/developers/docs/mev/index.md b/public/content/developers/docs/mev/index.md index 0b491e838c6..7d04757719b 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. diff --git a/public/content/developers/docs/networking-layer/index.md b/public/content/developers/docs/networking-layer/index.md index fb0737835a0..c04adcc328e 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) diff --git a/public/content/developers/docs/networks/index.md b/public/content/developers/docs/networks/index.md index eba69fc80f0..55321a1aad0 100644 --- a/public/content/developers/docs/networks/index.md +++ b/public/content/developers/docs/networks/index.md @@ -165,7 +165,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} 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. diff --git a/public/content/developers/docs/nodes-and-clients/index.md b/public/content/developers/docs/nodes-and-clients/index.md index 33768e35d66..bb7b81d45a9 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) 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 6e53fe3a4a5..11d89234fdf 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 @@ -226,14 +226,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 diff --git a/public/content/developers/docs/oracles/index.md b/public/content/developers/docs/oracles/index.md index 89367b1e804..0d1078e4f94 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. 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. 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} diff --git a/public/content/developers/docs/smart-contracts/anatomy/index.md b/public/content/developers/docs/smart-contracts/anatomy/index.md index fcee405be72..9c2e4c52468 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` diff --git a/public/content/developers/docs/smart-contracts/languages/index.md b/public/content/developers/docs/smart-contracts/languages/index.md index 395af3ad530..21c3f3b7e94 100644 --- a/public/content/developers/docs/smart-contracts/languages/index.md +++ b/public/content/developers/docs/smart-contracts/languages/index.md @@ -179,7 +179,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/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. diff --git a/public/content/developers/docs/smart-contracts/verifying/index.md b/public/content/developers/docs/smart-contracts/verifying/index.md index 6c2eeca919d..31c4dee31b1 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) 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 3e36ecad200..76394efa956 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?** 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 4bc510a41c0..90fc2d3f0de 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 `transfer(..)` 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. 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. diff --git a/public/content/developers/docs/storage/index.md b/public/content/developers/docs/storage/index.md index b8ad0b4cef7..66bcc57d35e 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. diff --git a/public/content/developers/docs/transactions/index.md b/public/content/developers/docs/transactions/index.md index 593195d99d6..c5175ec1529 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} 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: 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 ca341678640..1ad60c4f163 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://www.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 diff --git a/public/content/developers/tutorials/erc20-annotated-code/index.md b/public/content/developers/tutorials/erc20-annotated-code/index.md index 5313d3ef27d..5d3c598fb64 100644 --- a/public/content/developers/tutorials/erc20-annotated-code/index.md +++ b/public/content/developers/tutorials/erc20-annotated-code/index.md @@ -691,7 +691,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. * @@ -834,7 +834,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. * 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 f77c4943046..2103a95a558 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} 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 cc1512e4753..9aa5f7ae7a6 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://legacy.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 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: 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: diff --git a/public/content/developers/tutorials/nft-minter/index.md b/public/content/developers/tutorials/nft-minter/index.md index 82eafc4c3cc..25b670bd448 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. 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 060dc5804dd..8e92c065414 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 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} 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) diff --git a/public/content/energy-consumption/index.md b/public/content/energy-consumption/index.md index 3f1980071c3..07dc0b23694 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. diff --git a/public/content/governance/index.md b/public/content/governance/index.md index a0964e5afb2..d9d5c271585 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. 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 dfaa2ed2509..c112ea75e1e 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 @@ -61,7 +61,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? 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 7664a938c9d..ba6ac67e45e 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:** diff --git a/public/content/nft/index.md b/public/content/nft/index.md index 1243cde3952..7a4fcc225c6 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. diff --git a/public/content/prediction-markets/index.md b/public/content/prediction-markets/index.md index e9f6d5a5f84..977d9508741 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.  diff --git a/public/content/privacy-policy/index.md b/public/content/privacy-policy/index.md index 8b7f48b2465..9d448b8822e 100644 --- a/public/content/privacy-policy/index.md +++ b/public/content/privacy-policy/index.md @@ -54,7 +54,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. @@ -106,7 +106,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. @@ -133,7 +133,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. diff --git a/public/content/refi/index.md b/public/content/refi/index.md index 19b0f74f743..edca29a43f8 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: diff --git a/public/content/roadmap/danksharding/index.md b/public/content/roadmap/danksharding/index.md index 3c7df894deb..e84e6ccb6e9 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. diff --git a/public/content/roadmap/merge/index.md b/public/content/roadmap/merge/index.md index 7a5963d3c26..45fde3f311b 100644 --- a/public/content/roadmap/merge/index.md +++ b/public/content/roadmap/merge/index.md @@ -122,13 +122,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. @@ -153,7 +153,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. diff --git a/public/content/roadmap/merge/issuance/index.md b/public/content/roadmap/merge/issuance/index.md index d175d786e1f..cdcde539892 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} 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. diff --git a/public/content/roadmap/pectra/7702/index.md b/public/content/roadmap/pectra/7702/index.md index 9fe7faa8dbf..1101c25dfa0 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: diff --git a/public/content/roadmap/pectra/index.md b/public/content/roadmap/pectra/index.md index b5985b75485..63ae6ed27c6 100644 --- a/public/content/roadmap/pectra/index.md +++ b/public/content/roadmap/pectra/index.md @@ -66,11 +66,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} diff --git a/public/content/roadmap/pectra/maxeb/index.md b/public/content/roadmap/pectra/maxeb/index.md index 99cb491d20b..b4ad08a50ce 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/). 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} diff --git a/public/content/roadmap/statelessness/index.md b/public/content/roadmap/statelessness/index.md index ed13803139c..aad8c9e7209 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 diff --git a/public/content/security/index.md b/public/content/security/index.md index 01dcd61d43e..7269f69ea3b 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 by 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.** @@ -140,7 +140,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} diff --git a/public/content/smart-contracts/index.md b/public/content/smart-contracts/index.md index 25202805521..1386e527fd7 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} diff --git a/public/content/staking/pools/index.md b/public/content/staking/pools/index.md index 3733db9a0de..1a7c2492eb1 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/roadmap/merge/index.md b/public/content/translations/ar/roadmap/merge/index.md index bcba226004d..a7e6db5ce71 100644 --- a/public/content/translations/ar/roadmap/merge/index.md +++ b/public/content/translations/ar/roadmap/merge/index.md @@ -119,7 +119,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/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/bg/roadmap/merge/index.md b/public/content/translations/bg/roadmap/merge/index.md index e767e2cf7d5..3fc6a8b8cc7 100644 --- a/public/content/translations/bg/roadmap/merge/index.md +++ b/public/content/translations/bg/roadmap/merge/index.md @@ -119,7 +119,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/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/developers/docs/smart-contracts/languages/index.md b/public/content/translations/cs/developers/docs/smart-contracts/languages/index.md index a6c4919f696..7ba4c3e0b6f 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 @@ -179,7 +179,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/cs/roadmap/merge/index.md b/public/content/translations/cs/roadmap/merge/index.md index a94690be5a2..e33d6275ea6 100644 --- a/public/content/translations/cs/roadmap/merge/index.md +++ b/public/content/translations/cs/roadmap/merge/index.md @@ -122,7 +122,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/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/roadmap/merge/index.md b/public/content/translations/de/roadmap/merge/index.md index 60bc46d68e0..604930744fd 100644 --- a/public/content/translations/de/roadmap/merge/index.md +++ b/public/content/translations/de/roadmap/merge/index.md @@ -122,7 +122,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/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/roadmap/merge/index.md b/public/content/translations/el/roadmap/merge/index.md index 5a6c1017e0c..a3fdbf4c5ac 100644 --- a/public/content/translations/el/roadmap/merge/index.md +++ b/public/content/translations/el/roadmap/merge/index.md @@ -122,7 +122,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/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/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/es/developers/tutorials/erc20-annotated-code/index.md index 2f7419b697a..a31a3bf0a6c 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/es/roadmap/merge/index.md b/public/content/translations/es/roadmap/merge/index.md index f1d7499bc29..3b91bfc25a2 100644 --- a/public/content/translations/es/roadmap/merge/index.md +++ b/public/content/translations/es/roadmap/merge/index.md @@ -122,7 +122,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/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/developers/docs/smart-contracts/languages/index.md b/public/content/translations/fa/developers/docs/smart-contracts/languages/index.md index 27b2da99e29..079c3d5af1c 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 @@ -179,7 +179,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/roadmap/merge/index.md b/public/content/translations/fa/roadmap/merge/index.md index 3175ebda3e2..34666be4af0 100644 --- a/public/content/translations/fa/roadmap/merge/index.md +++ b/public/content/translations/fa/roadmap/merge/index.md @@ -120,7 +120,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/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/developers/docs/smart-contracts/languages/index.md b/public/content/translations/fr/developers/docs/smart-contracts/languages/index.md index b602168eb75..b31a6b37082 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 @@ -179,7 +179,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/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/fr/roadmap/merge/index.md b/public/content/translations/fr/roadmap/merge/index.md index 68bcf610482..48d1a7a4d64 100644 --- a/public/content/translations/fr/roadmap/merge/index.md +++ b/public/content/translations/fr/roadmap/merge/index.md @@ -122,7 +122,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/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/decentralized-identity/index.md b/public/content/translations/ga/decentralized-identity/index.md index 2fddf76c769..769e20be6ee 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} diff --git a/public/content/translations/ga/developers/docs/bridges/index.md b/public/content/translations/ga/developers/docs/bridges/index.md index f99109d164e..c775107123d 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ú. 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 ed7c29785d0..d2c02e4b0fd 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 @@ -21,7 +21,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} 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 02fdbd60ef3..a924c5ddbde 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 @@ -52,7 +52,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. 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 0645468f3e5..814f3a2c640 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 @@ -49,7 +49,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/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/ga/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md index a424875d442..ecdb48a0a0e 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 @@ -25,7 +25,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. 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 7904af05e8d..e018fb661a8 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. 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/gas/index.md b/public/content/translations/ga/developers/docs/gas/index.md index b33fcce1620..9b0028e98f6 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)_ 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} 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 eba463e5758..ee2b2587658 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/developers/docs/oracles/index.md b/public/content/translations/ga/developers/docs/oracles/index.md index 2345b97fa00..4211af40de7 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. 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 de9e76bb32c..fc01b39a280 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} 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. 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} 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 7682207d3b6..19962e7c6e0 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ó. 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 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_. 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. 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 32459ec3418..f8a333d4b49 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 @@ -179,7 +179,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/security/index.md b/public/content/translations/ga/developers/docs/smart-contracts/security/index.md index 3ac2698bdc2..551e45d3edb 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. 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. 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. diff --git a/public/content/translations/ga/developers/docs/transactions/index.md b/public/content/translations/ga/developers/docs/transactions/index.md index ccd129913b8..cd6366333ba 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} 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 25c9e0225f9..fb1fa832c09 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 @@ -61,7 +61,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? 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 9a626dac121..ccc56357035 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 @@ -61,7 +61,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? 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/roadmap/danksharding/index.md b/public/content/translations/ga/roadmap/danksharding/index.md index f9cd31d646c..668b8a873bd 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. diff --git a/public/content/translations/ga/roadmap/merge/index.md b/public/content/translations/ga/roadmap/merge/index.md index 148a08974b2..0330c0a7bf3 100644 --- a/public/content/translations/ga/roadmap/merge/index.md +++ b/public/content/translations/ga/roadmap/merge/index.md @@ -122,13 +122,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. @@ -153,7 +153,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/ga/roadmap/merge/issuance/index.md b/public/content/translations/ga/roadmap/merge/issuance/index.md index 537b23d4f7a..d5b42d64d5a 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} 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} diff --git a/public/content/translations/ga/security/index.md b/public/content/translations/ga/security/index.md index a0928136a81..290d3e421ff 100644 --- a/public/content/translations/ga/security/index.md +++ b/public/content/translations/ga/security/index.md @@ -139,7 +139,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} diff --git a/public/content/translations/ga/smart-contracts/index.md b/public/content/translations/ga/smart-contracts/index.md index f04ab176c1c..339c8ccfd56 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} 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/ga/whitepaper/index.md b/public/content/translations/ga/whitepaper/index.md index e0c1bc6eab9..52f57b8b7bf 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ú. @@ -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í”. @@ -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/ga/zero-knowledge-proofs/index.md b/public/content/translations/ga/zero-knowledge-proofs/index.md index a864667bccc..60752f08aa3 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. @@ -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/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/developers/docs/smart-contracts/languages/index.md b/public/content/translations/hi/developers/docs/smart-contracts/languages/index.md index 8e64c33911c..a010745ae6e 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 @@ -179,7 +179,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/roadmap/merge/index.md b/public/content/translations/hi/roadmap/merge/index.md index a4183f34afe..7b9ea43182f 100644 --- a/public/content/translations/hi/roadmap/merge/index.md +++ b/public/content/translations/hi/roadmap/merge/index.md @@ -122,7 +122,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/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/hr/roadmap/merge/index.md b/public/content/translations/hr/roadmap/merge/index.md index f0411812f96..e5eaaca15d1 100644 --- a/public/content/translations/hr/roadmap/merge/index.md +++ b/public/content/translations/hr/roadmap/merge/index.md @@ -119,7 +119,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/developers/docs/smart-contracts/languages/index.md b/public/content/translations/hu/developers/docs/smart-contracts/languages/index.md index 215bd3bd2bc..007bd430f67 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 @@ -179,7 +179,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/hu/roadmap/merge/index.md b/public/content/translations/hu/roadmap/merge/index.md index 82dd800f503..54fab5358bd 100644 --- a/public/content/translations/hu/roadmap/merge/index.md +++ b/public/content/translations/hu/roadmap/merge/index.md @@ -122,7 +122,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/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/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 da414b1cbb3..e89a0ece0c8 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/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. 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/id/roadmap/merge/index.md b/public/content/translations/id/roadmap/merge/index.md index 2c9034f72dc..9b82558cac2 100644 --- a/public/content/translations/id/roadmap/merge/index.md +++ b/public/content/translations/id/roadmap/merge/index.md @@ -122,7 +122,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. 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/) - + 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 21fcdfac57d..8783253b63f 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 @@ -179,7 +179,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) 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 a2cd2d25c8c..77d28e8c2a6 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. * 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)} /> 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 diff --git a/public/content/translations/it/roadmap/merge/index.md b/public/content/translations/it/roadmap/merge/index.md index c3c8b741c04..06cded798a0 100644 --- a/public/content/translations/it/roadmap/merge/index.md +++ b/public/content/translations/it/roadmap/merge/index.md @@ -122,7 +122,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. 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] - + 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 996a8fc9614..093d869dbcf 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 @@ -179,7 +179,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/ja/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/ja/developers/tutorials/erc20-annotated-code/index.md index ea9e8598906..56cf9b6b772 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. * 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)} /> 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 diff --git a/public/content/translations/ja/roadmap/merge/index.md b/public/content/translations/ja/roadmap/merge/index.md index 04b089ba24f..9bed7f65de0 100644 --- a/public/content/translations/ja/roadmap/merge/index.md +++ b/public/content/translations/ja/roadmap/merge/index.md @@ -122,7 +122,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/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/ml/roadmap/merge/index.md b/public/content/translations/ml/roadmap/merge/index.md index c04a866bc3b..2fdb8501a6a 100644 --- a/public/content/translations/ml/roadmap/merge/index.md +++ b/public/content/translations/ml/roadmap/merge/index.md @@ -119,7 +119,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 പോലുള്ളവ) ചുമതപ്പെടുത്തേണ്ടത് ആവശ്യമാണ്. 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 - + 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 0578c495a63..9c6c446f1e2 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 @@ -179,7 +179,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/nl/roadmap/merge/index.md b/public/content/translations/nl/roadmap/merge/index.md index 9b84c3a51f4..3d2d1007550 100644 --- a/public/content/translations/nl/roadmap/merge/index.md +++ b/public/content/translations/nl/roadmap/merge/index.md @@ -122,7 +122,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. 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 - + 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` 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 37b34dc2fd9..e1688fe7320 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 @@ -179,7 +179,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/pcm/governance/index.md b/public/content/translations/pcm/governance/index.md index 9be475b72c9..e3d3cfaec56 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. diff --git a/public/content/translations/pcm/nft/index.md b/public/content/translations/pcm/nft/index.md index 0938bad137b..5880856800b 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. diff --git a/public/content/translations/pcm/security/index.md b/public/content/translations/pcm/security/index.md index e2db55bb503..d91454ef534 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.** @@ -139,7 +139,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} diff --git a/public/content/translations/pcm/smart-contracts/index.md b/public/content/translations/pcm/smart-contracts/index.md index 6418c16825f..cbcaf10f862 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} 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 - + diff --git a/public/content/translations/pcm/whitepaper/index.md b/public/content/translations/pcm/whitepaper/index.md index b920b3f0dc3..71099625a9f 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: @@ -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. diff --git a/public/content/translations/pcm/zero-knowledge-proofs/index.md b/public/content/translations/pcm/zero-knowledge-proofs/index.md index 7f3a96ebed7..08d13538971 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. @@ -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} 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 75a14e3e665..63ec7dcbb46 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) diff --git a/public/content/translations/pl/roadmap/merge/index.md b/public/content/translations/pl/roadmap/merge/index.md index 0812de729b1..98946287a3c 100644 --- a/public/content/translations/pl/roadmap/merge/index.md +++ b/public/content/translations/pl/roadmap/merge/index.md @@ -122,7 +122,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ą. 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 - + 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. 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 6a438f42ca6..bd328aaf93c 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. * 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)} /> 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 diff --git a/public/content/translations/pt-br/roadmap/merge/index.md b/public/content/translations/pt-br/roadmap/merge/index.md index 3b46871c818..ac9880b77b8 100644 --- a/public/content/translations/pt-br/roadmap/merge/index.md +++ b/public/content/translations/pt-br/roadmap/merge/index.md @@ -122,7 +122,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. 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/), - + 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: 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 - + 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 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 a80a8549c5c..8dd7d6bd2bc 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. 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ă: 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. 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 diff --git a/public/content/translations/ro/roadmap/merge/index.md b/public/content/translations/ro/roadmap/merge/index.md index fc595ad299f..94ae58d91c9 100644 --- a/public/content/translations/ro/roadmap/merge/index.md +++ b/public/content/translations/ro/roadmap/merge/index.md @@ -115,7 +115,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. diff --git a/public/content/translations/ru/roadmap/merge/index.md b/public/content/translations/ru/roadmap/merge/index.md index 9e8d4afd335..b6989c31d89 100644 --- a/public/content/translations/ru/roadmap/merge/index.md +++ b/public/content/translations/ru/roadmap/merge/index.md @@ -122,7 +122,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/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/sl/roadmap/merge/index.md b/public/content/translations/sl/roadmap/merge/index.md index 4422f0261a4..96a211f4736 100644 --- a/public/content/translations/sl/roadmap/merge/index.md +++ b/public/content/translations/sl/roadmap/merge/index.md @@ -119,7 +119,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. diff --git a/public/content/translations/tl/governance/index.md b/public/content/translations/tl/governance/index.md index 9cf84c2f503..1b994e26379 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._ 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/developers/docs/smart-contracts/languages/index.md b/public/content/translations/tr/developers/docs/smart-contracts/languages/index.md index 672c63a0993..1ece0c4904c 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 @@ -179,7 +179,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/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)} /> 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 diff --git a/public/content/translations/tr/roadmap/merge/index.md b/public/content/translations/tr/roadmap/merge/index.md index 05b67d363e1..e69b0e26514 100644 --- a/public/content/translations/tr/roadmap/merge/index.md +++ b/public/content/translations/tr/roadmap/merge/index.md @@ -122,7 +122,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. 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/roadmap/merge/index.md b/public/content/translations/uk/roadmap/merge/index.md index ee4156ee1c7..8a6bd485c39 100644 --- a/public/content/translations/uk/roadmap/merge/index.md +++ b/public/content/translations/uk/roadmap/merge/index.md @@ -122,7 +122,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/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 - + 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 - + 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 f558b66fb31..032b0c755d4 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 @@ -176,7 +176,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/zh-tw/roadmap/merge/index.md b/public/content/translations/zh-tw/roadmap/merge/index.md index 3b7e211a40b..70f46862a28 100644 --- a/public/content/translations/zh-tw/roadmap/merge/index.md +++ b/public/content/translations/zh-tw/roadmap/merge/index.md @@ -122,7 +122,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/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: - + 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 061235abb14..98d353b80bb 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 @@ -173,7 +173,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/zh/developers/tutorials/erc20-annotated-code/index.md b/public/content/translations/zh/developers/tutorials/erc20-annotated-code/index.md index d2fef76a3a2..a1927070a0a 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. * 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)} /> 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 diff --git a/public/content/translations/zh/roadmap/merge/index.md b/public/content/translations/zh/roadmap/merge/index.md index b7dc09a114f..95924cb71e1 100644 --- a/public/content/translations/zh/roadmap/merge/index.md +++ b/public/content/translations/zh/roadmap/merge/index.md @@ -122,7 +122,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/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: - + diff --git a/public/content/whitepaper/index.md b/public/content/whitepaper/index.md index a6374ee6322..fe529686eac 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. diff --git a/public/content/zero-knowledge-proofs/index.md b/public/content/zero-knowledge-proofs/index.md index 7dd44a244d5..506dd58ca6f 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. @@ -94,7 +94,7 @@ For example, [quadratic funding mechanisms](https://www.radicalxchange.org/wiki/ 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} 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 ? [ { 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 */
"new-term" is the `termKey` + // e.g., in `/glossary/#new-term` => "new-term" is the `termKey` if (matches?.length) { const termKey = matches[1] 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 */ diff --git a/src/components/ui/Link.tsx b/src/components/ui/Link.tsx index b284db06acf..c3839bd5bb6 100644 --- a/src/components/ui/Link.tsx +++ b/src/components/ui/Link.tsx @@ -46,13 +46,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( { 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, diff --git a/src/intl/en/glossary.json b/src/intl/en/glossary.json index 377293848ce..f0af1389a38 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", @@ -114,7 +114,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", @@ -136,7 +136,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", @@ -274,7 +274,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", 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/en/page-bug-bounty.json b/src/intl/en/page-bug-bounty.json index bd16ed4b0ce..c9f72f7db2a 100644 --- a/src/intl/en/page-bug-bounty.json +++ b/src/intl/en/page-bug-bounty.json @@ -21,7 +21,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", diff --git a/src/intl/en/page-staking.json b/src/intl/en/page-staking.json index 8865214fe4b..cbce73d7993 100644 --- a/src/intl/en/page-staking.json +++ b/src/intl/en/page-staking.json @@ -201,7 +201,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/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.", 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ú", diff --git a/src/intl/ga/page-staking.json b/src/intl/ga/page-staking.json index 020f428111f..5a5836f16af 100644 --- a/src/intl/ga/page-staking.json +++ b/src/intl/ga/page-staking.json @@ -201,7 +201,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 15d0f9eb457..6bf6f21d4bb 100644 --- a/src/intl/pcm/page-staking.json +++ b/src/intl/pcm/page-staking.json @@ -200,7 +200,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 da24265df65..201eed1506e 100644 --- a/src/intl/yo/page-staking.json +++ b/src/intl/yo/page-staking.json @@ -182,7 +182,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è.", 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` diff --git a/src/scripts/markdownChecker.ts b/src/scripts/markdownChecker.ts index 8bfbdd09ecc..85b080f1617 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"